Project Methodologies: The Right Mix

I was thinking about a fancier name for the article, but decided in favor of a simple and straight forward one as it is more akin to the spirit of the article. Simple, crisp and straight from the gut.

Today we have various methodologies doing the rounds, including but not limited to the various flavors of Agile. We also encounter various life cycle models starting from the plain vanilla Waterfall model to the more esoteric ones. Usually experts tend to lean towards one or the other methodology and try to promote it as the panacea to all issues that plague project management. The other issue that I have encountered is that very few experts write from a perspective of service companies where all projects executed are the ones outsourced by the customer. In this scenario, the commercial engagement model has a significant relevance while selecting the methodology.

In this article I would like to share what I found to be the right mix, even though I have not thought about assigning any new name to it. I would highlight the practices which I have found to have made a positive impact on the health of the project, while avoiding the associated frills. Now, let me jump straight to the point.

Choosing the right life cycle model:  Talking about life cycle models, the two significant and most followed ones are Waterfall and Iterative models. Choosing the right one between these to suit the engagement model is the real issue. Usually the most common types of engagement are fixed price; and time and material. We will continue to refer to these models as FP and T&M in the rest of the article. From my personal experience I have found, that it is disastrous to assign an Iterative life cycle to an FP engagement. In today's scenario where companies have become sensitive about every dollar they spend, customers almost always demand to see an early version of the product. However, the stakeholders in a project very often fail to appreciate the difference between incremental delivery and iterative development. While incremental delivery merely focuses on phasing the project in terms of delivery milestones and associating deliverables with each milestone, iterative development moves with the premise that the complete set of requirements are not known at the start of the project and each iteration therefore constitutes all the phases of the SDLC. Since new requirements can evolve at each iteration, prior estimation of the complete project is not possible. This is the reason why we can not associate an Iterative model with FP engagement.

Documentation: Whatever the various methodologies profess, documentation is still a very important aspect of project management. All the requirements must be properly documented and traced till completion. A few documents like the Requirement Specification and the Requirements Traceability Matrix are extremely important to maintain. What needs to be kept in mind is that the requirements must be documented at a highly granular level and all changes should be updated in the document without any delay. The documents themselves should be maintained in a repository and a rigorous configuration management plan should be in place. There are people who argue against documentation but in a contractual scenario till date there is nothing to beat an approved, version controlled document.

Plan and Schedule: Plans are important as they force you to foresee certain aspects which otherwise would have gone unnoticed. Plans should be made at the onset of the project and stored in the repository. But we should not forget that any plan should be dynamic in nature and should be updated as and when required. Scheduling for the project should be done at the beginning of the project. If the project follows an waterfall model, the schedule for the entire project should be in place at the onset but in case of an iterative model we can live with having the schedule drawn up for the current and possibly the immediate next iteration. Using a good tool like the MS Project or Open Workbench is important for midsize and large projects.

Risk Management: Risks need to be actively tracked at every stage using a risk repository. Every risk needs to be assigned a probability and an impact value, based on which the team should draw a mitigation plan and a contingency plan for each risk item. I personally prefer to use a scale of 1,3 and 9 where 1 is low and 9 is high. A product of probability and impact gives the magnitude of the risk. If it is 27 or more the risk item must have both mitigation and contingency plan. For anything less, just the contingency plan can work.

Trackers: Effective use of a query tracker and an issue tracker can help the project stay in its tracks. While various tools can be used for this purpose, in absence of anything a simple spreadsheet can do the trick.

Configuration Management: It is extremely important to follow a strict configuration management procedure in a project. The configuration management plan should be drawn up at the onset of the project and a configuration controller should be selected from the project team members. This person should follow the plan rigorously and ensure the health of the repository.

Meetings: From my experience I have seen that a daily morning meeting preferably with the help of a visual display medium such as a whiteboard, is an effective tool for keeping the project in track. These meetings should not be more than 30 minutes. The primary agenda should be to assess the progress of tasks, identify the day's tasks and identifying the roadblocks. This meeting should be used only for identifying issues and not resolving them.

Test Driven Development: This is an engineering aspect of project execution rather than a management aspect. But I have still chosen to highlight this because this aspect very often decides the success and failure of a project. It is extremely important to follow a proper unit testing procedure, preferably using a tool such as NUnit or JUnit. Only when the code passes this gate it should be handed over to the testing team for functional testing. This step ensures that developers hand over a relatively error free product to testers and the testers can concentrate mainly on the functional aspects.

Continuous Integration: This is another engineering aspect and is also important. If we wait till the end to integrate and do functional testing, the cost of fixing will be high. It is rather easy to fix issues if the product is tested at the early stages of the project.

Most or all of these points are common knowledge. But very often projects fail because we as project managers fail to address one or more of these areas properly. I do not think that I am injecting any new ideas here, but this is a reiteration of the factors that make a project successful. I hope to hear from people if they have any further ideas to share.