Monday, January 23, 2012
Lesson No. 2: Make Project Sponsors Write Their Own Requirements
Before we begin on this topic, doesn’t the title seem impossible? Do you really think the Project Sponsors (Senior Business Managers and others high up in the corporate food-chain) will spend time writing requirements? If you arent sure, just keep thinking in the background and we will get to it pretty soon before we end this chapter.
In any country, any industry, the key reason for project failure is “Poor Requirements Definition” Though PMI recommends a clear and well defined requirements gathering phase as a mandatory part of any project’s lifecycle, in real life, that is rarely the case. In real life, teams are asked to begin development even before the preliminary or rough specs are signed-off.
The companies that are most at risk are those with poor business analysis capabilities. When specifically reporting on technology projects, such as software development, success is categorized, euphemistically, as "improbable." This result shows how difficult it is to find, identify, and define true requirements for a software project.
The software project manager usually does not have the authority or the time to find, select, and prioritize the project requirements on their own, especially since there may be several interest groups involved in the project that probably have conflicting ideas about what they envision the software will do upon completion.
It's up to the project manager to spend time with those who are funding the software project to help them define exactly what they want before the project starts. Is it more important that it is done quickly, with few bugs, or on as small a budget as possible? You can't have it all. What resources and skill sets are crucial to create the software they want? Are they making these resources available to the team?
Without serious, specific consideration of what is to be created on this project during the requirement definition phase, the success of the project is severely under question. Remember, project owners need to convey what they want this software to do, not how the programmers will go about producing that result.
Go back to the first paragraph of this post and re-read it. If you are someone with that kind of doubt, then you need to read the subsequent two paragraphs as well.
Convince the project owners that they must be involved in the process from start to finish. Solid requirements planning establishes a clear connection between the business case, project goals, and the project outcome. Otherwise, the project cannot produce the satisfactory result they are expecting.
A failed software project hurts the project owners most, since they have put up the money to fund the project and were expecting to use the software to earn back their investment.
So, if you want to be a good manager and a successful one too, try to convince your project sponsors to take part in defining/baselining the project requirements. This will eliminate undue surprises
Previous: Lesson No. 1
Subscribe to:
Post Comments (Atom)
© 2013 by www.getpmpcertified.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.
Followers
Popular Posts
-
So far, we have been talking in terms of projects only. There are two other terms that are closed linked with projects and project manageme...
-
In the previous chapter, we saw how to create the Project Scope Document. The next step in planning for a projects scope is to create the Wo...
-
In the previous chapter, we saw the project lifecycle in detail. In this chapter, we are going to take a look at the Project Management Kno...
-
In the previous chapter , we took a look at Expected Monetary Value or EMV Analysis . The Decision Tree Analysis is another tool/technique ...
-
In the previous chapter we learnt how to create the project human resource plan. To get resources you need to spend money (Cost) and you can...
-
In the previous chapter , we learnt the basic details about Continuous Distributions. In this chapter, we are going to take a detailed look...
-
In the previous chapter we learnt that the risk register is going to be constantly updated as we progress through the various processes in...
-
Expected Monetary Value Analysis or EMV Analysis in short is the 2nd tool and technique in the Quantitative Risk Analysis and Modeling Tech...
-
In the previous chapter, we saw that an organizations policies and culture can have a significant impact on a project. Towards the end we al...
-
In the previous chapter, we took a look at how the organizational structure can affect a project and how it affects the life of a Project Ma...
No comments:
Post a Comment