Software project management as a field has matured significantly over the past couple of decades and the industry standard frameworks such as the CMMi and PMBoK have played their role in this progress. This raises an interesting question as to what extent these frameworks can be relied upon to ensure successful delivery. Are they complete by themselves or constitute only a part of a complete solution? And if partial what are the additional practices needed to complete ?
To elaborate, let us understand how this question matters to different stakeholders in software delivery:
The CMMi and PMBoK have many similarities and differences as well. It would be out of scope for this article to examine these differences, and the article will be treating the superset of practices of both the frameworks as a whole
Capabilities: The practices prescribed in the frameworks provide complete solution to a number of issues in software delivery:
Limitations: The limitations are many and cut across multiple areas such as soft skills of project managers, experience, software engineering, technological aspects such as architecture and so on. However, the fact that technology related skills, soft skills and software engineering skills are out of scope for CMMi and PMBoK is well understood. Therefore, this article will be focusing on 3 areas, which are considered very critical to project success, that are within the scope of CMMi and PMBoK, but don’t address adequately and requires software organizations to stretch much beyond implementing CMMi and getting their staff trained on PMBoK.
Solution: Striving to achieve clarity and completeness in requirements elicitation by taking care of internal factors is a practice that IT teams need over and above the industry frameworks. Requirement changes due to internal factors can be eliminated by eliciting requirements from the right stakeholders and usage of right elicitation techniques.
Solution: First part of the solution is to reduce the changes by improving requirements elicitation. Second part of the solution is to eliminate requirement changes arising out of communication gap – this needs a good requirements document to the right level of detail. Third part of the solution is to have shorter release cycles and when requirement change does occur, it must be subject to a filter – whether the change asked for adds business value? If the change is important for business, can it be incorporated in the next release? After passing the change through these questions, if it turns out that the change is a must for the current release, then the change control procedure should be applied. In summary, how the change control procedure must be leveraged, is an insight that IT teams need beyond CMMi/PMBoK
Estimation accuracy: While the CMMi and PMBoK stress on cost estimation, they don’t offer estimation methodologies that can accurately estimate the effort. This is another area where delivery teams have to look for practices beyond the frameworks.
Solution: There are many technology specific estimation methodologies that are in practice today and some of them can be leveraged.
Unusable project schedules: Many times the schedules drawn up using MS project are not used for driving the project. The task sequence and task durations in the schedule do not reflect ground reality, resource loading would not be optimal and as a result, the project schedule is only updated based on ground situation that takes shape independent of the schedule. Ideally, the ground situation should be driven based on the schedule. This laxity allows project schedules to slip out of control.
Solution: Well researched, step-by-step procedures can be used to draw usable schedules. How to draw up schedule is an area not addressed by the CMMi / PMBoK frameworks
There are many other software delivery areas beyond CMMi and PMBoK such as software engineering excellence, test case optimization etc that demand attention and this article has highlighted only the most important ones. Implementing advanced practices in these areas can be highly beneficial. In one case study that I know of, a software service organization has implemented these practices across multiple projects and this has resulted in measurable improvements. Across a sample of 36 projects, the effort overrun was reduced by more than 10% and defect rate was reduced by more than 10 times.
summary, how the Indian IT industry will grow in the next couple of decades depends on a number of factors. But, explosion of easy-to-use-and-customize apps doesn’t necessarily pose a threat of IT departments being displaced and replaced by business users turning into part-time developers. And in that sense, Indian IT industry doesn’t face a significant business threat from explosion of open source apps.
What do you think? Do you find any flaw in the argument? Do you have alternate points to emphasize the same conclusion? Do share your opinion in the comments.
