In 1986, Fred Brooks, professor at the University of North Carolina at Chapel Hill, authored a paper entitled No Silver Bullet-Essence and Accidents of Software Engineering in which he argued that“there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.” He identified a number of techniques and approaches that many people were hopeful were going to solve the age-old dilemma facing most complex software development projects: they take too long and they cost too much.
Brooks ought to know, he was the father of the IBM Operating System 360 and wrote of his experiences in the classic book The Mythical Man Month. Ultimately, not one of the techniques and approaches, in and of themselves, were able to solve the dilemma software developers faced at that time. And, today, that dilemma remains largely unsolved.
However, in a recent Pulse of the Profession Report entitled Requirements Management A Core Competency for Project and Program Success, the Project Management Institute’s (PMI) in-depth study finds “that when projects do not meet their original goals and business objectives, inaccurate requirements management is the primary cause of that outcome almost half of the time (47 percent).” Such a finding suggests that an organization can really boost project success if they simply get this part of the process correct. In fact, PMI is so convinced that there is such great promise in this area that it has launched a new credential and is preparing guidance to help out in this area. That’s great for the industry and for us as practicing project managers. Any help we can get with our work we appreciate. But will all this focus help? Yes, but not to the extent it could. Why? Here are few reasons I’ve thought of.
1. Executives and others simply will not believe the data in PMI’s or anyone else’s report. They’ll claim PMI and IIBA (who has had a couple of credentials and good guidance for years) are self-serving organizations and all their work is designed to promote themselves and sell more credentials.
2. Organizations will continue to launch more projects than they have the resources to handle. Just ask any project manager anywhere what one of their main problems is and they’ll invariably say something about resources. I just attended a session the other day where, when asked by the facilitator what the main cause of issues regarding executing strategy, most people said, “too many projects.”
3. Many organizations will continue to insist, largely for cost containment purposes, that the project manager should be the person responsible for identifying and gathering requirements. Therefore, they will not fund having a business analysis on the team. (This is the same ill-advised approach many take when the project manager is also the project scheduler by the way.)
4. There are quite a few people in the universe who don’t even know what a business analysis is. Those that do tend to be in the IT field. Outside of that, you don’t even find many people who carry the title.
For this initiative to really gain traction requires that PMI, IIBA and others (I know that IIBA has been trying to promote this for years with their BABOK and certifications) spend a great deal of time educating executives and managers on the benefits of a strong requirements management practice, encouraging them to keep their portfolio’s in check by not doing too many projects at once (it’s called portfolio management), and on convincing them that the skills of a business analysis are vastly different, and superior, to the project manager’s as they relate to requirements management. This is no small hurdle.
If these things are not done, the great reports and findings, guidance and credentials (e.g., PMI-PBA) will, unfortunately, not the have the affect intended by all those who are convinced that, although not a silver bullet per se, can sure help those in the trenches get the job done.