On Product Development and More...

As I previously wrote, MS Project is a really useful tool, particularly, for modeling "what if" scenarios. It's also quite useful for tracking project status.

With that being said, a common complaint that I hear (from project managers, development managers, test leads, etc.), is that the effort required to keep the model up-to-date is too high - particularly in the world of software product development - where change is the order of the day.

There are, of course, much easier ways to track project status. For organizations that are looking for a simpler way to approximate status, I recommend using a burn down chart. Its magic is in its simplicity. We simply need to do track the Estimate to Completion across the team.

It’s particularly easy to create a burn down chart when using an agile development methodology. But what if you are not a pure agile shop? A number of software companies that I have worked with use a hybrid model - that leverages concepts from both the iterative and agile methodologies. This type of software development methodology (which I refer to as "Ragile" - a combination of RUP + Agile) consists of various phases including:

• A Development Phase which is characterized by frequent iterations (typically, these are 1-3 week in duration). During the Development Phase, while the Engineering team is designing and building code, the Testing team is writing test cases and designing test data. When the Engineering team has completed building the code for one iteration (which, of course, also includes invoking unit tests), the Testing team executes their test cases. Issues encountered by the Testing team are either fixed immediately (if Test blockers are discovered) or fixed in a follow-on iteration (when non Test blockers are discovered).
  
• A Testing Phase is then used to stabilize the product. During the Testing Phase, the Testing team performs both functional (including a System Test) and non-functional testing (including Installation, Upgrade, Performance, Concurrency and Reliability Testing). It's important to note that while this type of testing can be performed at any time (i.e. during the Development Phase), it must be performed after the Development Phase, once all features are implemented. Why? Because any feature built by the Engineering team could, at least theoretically, introduce instability into the software product.

So, how do you track status in this situation? Without a doubt, it's a bit more complex than the pure agile model. But only slightly more. You simply need to independently track Estimate to Completion for both the Engineering and Testing teams. You measure:

• Estimate to Completion for the Engineering team through the end of the Development Phase and
  
• Estimate to Completion for the Testing team through the end of the Testing Phase

Without a doubt, there is some subjectivity involved in whether the project holistically is on track (across both the Engineering and Testing teams through both the Development and Testing phases). For example, the Engineering team could be ahead of schedule, but the Testing team could be behind schedule (vis a vis plan). Or, the Engineering team could be behind schedule, but the Testing team could be ahead of schedule (vis a vis plan).

Despite this, by capturing Estimate to Completion, you have a fairly good reading of where your project is. And you can use this information to make better business trade-off decisions. Throughout the product development lifecycle.