This week, as if to keep our long romance “alive”, my car throws me a new dash board warning:
I laughed out loud. My first thoughts were that they’ve really over engineered this car to have the display tell me that the display itself is about to die. Over the course of this short drive I concluded this was likely done by design and not over design:
1. The display itself is important for so many other messages that replacing it soon was a good idea
2. The system reports on every other aspect of the car so not including the display itself would seem like an incomplete design.
Now that I solved this very important mystery of life I could not resist letting my mind wander on similar instances of apparent over design or over thinking something. Project metrics came to mind and how they are often undervalued or overvalued on a project.
Most anyone who’s been in product development for a while has seen it; companies often make the mistake of paying too little or too much attention to project metrics. Both can kill a project (or career) so the question is “where’s the sweet spot”. As with such topics there are lots of really good books out there on what metrics you can collect and how to “read the tea leaves” of those metrics, however I’ve found that few books effectively address:
1. What metrics should be collected for this particular project?
2. Of those collected what should be reported on?
3. What triggers and plans are in place to detect and correct an undesirable trend?
4. If undesirable trends are not being acted on then should those be discontinued?
I have personally found that management (me included) often make the mistake of prescribing “key metrics” to the project teams because the latest book said these are good metrics to follow. Such management direction is also done without buy in from the team members and not regularly reviewed for project impact and relevancy.
In my next blog entry I will explore this topic further and welcome your comments and suggestions.
With a BS in Computer Science from Chapman University, Michael has spent 20+ years in software development doing: coding, research, development, customer facing, system architecture, team building, and early stage (pre-funded) startups. Michael was first at Rockwell International designing software for an embedded systems radar system, image processing, and navigation systems. Between 1993 and 2001 Michael was a consulting software developer for several companies including Sony, Nortel, IBM, and Motorola. In 2000 and 2001 Michael co-founded two separate startups specializing in voice recognition and web technologies. Michael has over 24 software and web technology patents and is now a Project Manager for Agile software projects. Feel free to engage Michael via email: MichaelEmens@gmail.com