.:blog.iainmcdonald

stuff

Continuing on with the old doc I found on out of control projects, here is the next installment.  It's not by me - it was written by Chris Williams in 1995. This section is called Product:

It’s often easy to look at the product itself and judge whether the project has a good chance of success. This is where an objective third-party view, that of another experienced project manager, can help the most.

Difficulty making the transition from technology to product

Version 1.0 of any product is more inclined to be out of control, or at least appear that way, because the target can move or be unclear. Much of the difficulty can happen in the transition from technology to product. This transition, where a great piece of technology gets solidified into something a customer would pay money for, is, from all experiences here, a very difficult one.

The key flag for a product that is not successfully making this transition is a team that is in love with the technology. They are so enamored of it that they can’t articulately identify who the customer is, why the customer would want it, and how their technology fits into a business model. They often redirect questions in this area to demonstrations of the technology, or to detailed discussions of how it works.

People in love with the technology also often have a difficult time discussing version 2.0 or 3.0 of the product. They’ve become so engrossed in what it is today that they haven’t thought about how it will be a business in the long run.

Biting off too much

If you review the project with an experienced project manager and their response is that this looks very hard, this is a danger sign. Every project shouldn’t be easy, but then again, they should be doable.

There is a tendency, especially again with version 1.0 projects, to feel compelled to make a big hit with the product. This can lead to over-ambitious projects that are destined to have difficult births. Often this is caused by fear of a competitor. We worry that we’ll make an inadequate response to their latest release, and that we’ll be a failure in the marketplace.

But one of Microsoft’s key strengths is our persistence and willingness to stick with products, even those that start with humble beginnings (Windows, Word for Windows, Windows NT). This should provide comfort and cushion for projects that need to limit their round one goals to a more achievable set.

The solution is to make a project plan that covers several manageable releases. Plan version 1.0 to build a solid foundation and establish a position in the market. Leave for version 2.0 or 3.0 those features that will make the project late, or that require time in the marketplace to jell.

This is a tough decision. Everyone wants to make a splash. But experienced managers will all tell you that, after five years, they would rather be working on version 3.0 of a product than working on the fifth year of version 1.0.

Too many dependencies

Dependencies on other projects are an unavoidable fact of life. And as we, as a company, move to a more component architecture, the number of dependencies for any one project is increasing. This is clearly a good goal as we can leverage our size and allow groups to specialize in areas of their expertise.

Years of experience at Microsoft have taught the most veteran Program Managers to avoid dependencies at all costs. This is clearly an exaggeration and can lead to rampant duplication of effort. But the lesson is clear: a project with key functionality being delivered by another group needs to manage that dependency very closely. And a project with most of its functionality in the form of dependencies is a project likely to be in trouble.

No, or very little, specs

This is becoming rarer at Microsoft, but the tendency to “fly by the seat of your pants” is a danger sign. No project should exist without some common point of reference, and a spec is a very good example of one. Especially at the beginning of a project, before coding has begun, the spec is the only deliverable, and the only real sign of progress in the group. Once well into a project, the product becomes a more visible indicator, and should be trusted far more than any document, but at the beginning some documentation is a must.

Extremely detailed spec

The converse to having no specs is having an encyclopedic spec. Communicating the project to the team and its dependents is key, but an extremely detailed spec can be a problem for a couple of reasons.

An overly detailed spec is a warning sign because it can, itself, become the deliverable. The team can get overly focused on updating it, on filling in every little hole, or on producing regular updates. It is an indicator that the team has lost the focus on the end product, and has forgotten that the key deliverable is a product for our customers.

Another way that too much spec can be less than a good thing is that it breeds overconfidence. By having an apparently bullet-proof spec, a team can fail to prepare for the inevitable calamity or change in direction. They will schedule things with inadequate buffer, they will be resistant to changing it for all but the most dire of causes, and will lose sensitivity to the market they are trying to serve.

So how much is too much? This obviously varies with the product, but the warning signs are fairly easy to spot. Is the spec in numbered volumes? Has the spec been read, really read, by anyone other than the author? Is the spec the review objective for the program manager, as opposed to a good feature in the product? Is updating the spec someone’s full-time job? These are not necessarily fatal, but often indicate a problem.

The vision in the wind

Often used as the excuse for a project’s problems, but only occasionally correct, is the project whose vision changes every few months. This has been the downfall of more than one project, and is usually blamed on “management.” The reality is more often that the project never had a clear vision in the first place, or the vision failed to take into account some crucial elements (the customer, for example).

Detecting this problem is rarely difficult, teams will usually howl in pain with each change of the vision. Clearly changes in the individual features or minor project goals are commonplace. The time to worry is when the fundamental direction of the project changes but the shipment deadline doesn’t.

Not managing product performance and size

Features can be debatable: which should be in, which should be out, it’s always a question. But the areas of product functionality that are constant and most frequently overlooked are performance and size. Failure to pay heed to these issues will always come back to haunt the team, and can be an early warning sign to a product doomed to be out of control.

The product team must clearly specify performance and size goals for every significant part of the product. If they are not managing these issues by monitoring their progress toward these goals with their daily builds, they are going to be surprised at the end of the project. If they have no time in the schedule to fix performance and size problems, they will likely slip. If they have no people to worry about this as their primary job function, they are likely to ship a pig of a product. In any of these cases, they are not in control.

<iain again> He says it better than I do.  I say stuff like "we don't ship the spec"  So many of the things above have happened to me.  Repeatedly…