| p>(How to resist the temptation to "boil the ocean") | | | | Additions to the software system which are |
| The most common reason for software project failure | | | | unacceptable to your project may be ideal candidates |
| is not failure to control budget or schedule but failure to | | | | for the next project. Software systems are never |
| control requirements, either at the outset or during the | | | | static; they are constantly changing and evolving so |
| build phase. Software projects are unlike those that | | | | they should have a process for capturing new |
| deliver a tangible product such as a building, a bridge, or | | | | features or fixes for the next system release. Ensure |
| a dam. These projects receive much more attention | | | | that your project has a direct connection between its |
| during the planning phase and tend to be controlled | | | | change management system and the production |
| with much more rigor than are software projects. | | | | change management system. Changes that would |
| You'll never hear of a plan to build a 20,000 square | | | | add too much to the scope of the current project but |
| foot shoe store ballooning into a project to build a 10 | | | | that are otherwise supported by a sound business |
| acre shopping mall! Yet that's exactly what happens to | | | | case should be assigned to the production feature |
| a lot of software projects. They start off with one | | | | pool. This approach has two advantages: it doesn't |
| objective in mind but after the last stakeholder has | | | | lose sight of the value-add feature being requested |
| added his or her wish list they bear no resemblance to | | | | and it isn't an outright rejection of the requested |
| the original vision. I call this dispersion of focused effort | | | | change. |
| "ocean boiling". It's not an original term but I think it fits | | | | Don't forget that the cost of the project must include |
| this situation perfectly. Attempts to boil the ocean will | | | | project management activities such as project |
| expend a great deal of heat without changing the sea | | | | communications, meetings, workshops and other |
| state. Attempts to deliver an extensive wish list of | | | | management functions. Your organization may already |
| software features will spend a great deal of cash | | | | have a well defined management methodology which |
| without changing the business. | | | | you are expected to follow, otherwise you should be |
| Failure to maintain a narrow focus on the original | | | | managing it using the best practices in the industry (the |
| objective of the project leads to overruns of both | | | | Project Management Body of Knowledge, or PMBOK |
| schedule and budget. I'm using the original budget and | | | | 4th Edition describes these very well). Make certain |
| schedule here as we frequently see projects which | | | | that the work that you plan to do to manage the |
| have their budget and schedule changed during the | | | | project is captured in the Project Charter and/or |
| course of the project, using the appropriate change | | | | preliminary Scope Statement. Requests for additional |
| management processes labeled as cost overruns and | | | | work should be treated the same way as other |
| late deliveries based on their deviation from the original | | | | requests to expand the scope. |
| plan. Clearly, whether these projects are "on budget" | | | | A Statement of Work (SOW) will usually accompany |
| and "on schedule" is a debatable point. The real point | | | | an RFP or RFQ when work is being done by a vendor |
| here is that a certain degree of deviation from the | | | | for a client. The SOW will usually be much more |
| original budget and schedule is acceptable but when | | | | precise and detailed in its description of the work to be |
| the scope of a project experiences a significant | | | | done but not always. Make sure that the SOW you're |
| increase budget and schedule are sure to increase | | | | working from is detailed and includes a description of |
| beyond what all stakeholders will find acceptable. Think | | | | the project management functions and artifacts you |
| how many times you've read or heard about overruns | | | | will be responsible for. Duties, meetings, reports, and |
| on government projects in the media. The media rarely | | | | communications that were not identified in the SOW |
| mentions whether these "overruns" are the result of | | | | should be addressed through change requests. |
| approved change requests; their only point of | | | | Change requests which would significantly alter the |
| reference is the originally announced schedule and | | | | scope of the project should not be an issue. If it does |
| budget and anything more is an overrun. You may not | | | | become an issue, it will be the customer's issue |
| be working on a government project but it is still | | | | providing you have a well prepared SOW. |
| important to curtail project scope for the organization | | | | Verify that you can deliver the scope of the project |
| you are working for. | | | | as it has been defined for the budget allocated to the |
| This article is not meant to be a comprehensive | | | | project and in the time given. This will probably be |
| course on scope management, merely to offer a few | | | | relatively easy when the project is similar to ones |
| helpful tips that will help you avoid managing a project | | | | routinely undertaken by your organization, or for |
| that is perceived by your stakeholders to overrun | | | | smaller projects. More thought should be given to the |
| budget and schedule. Those of you who haven't | | | | project approach when tackling a very large complex |
| invested in project management certification should | | | | project for the first time. Pilot projects and prototypes |
| take a good PMP course or other PMP exam | | | | can be used to learn more about the cost and effort |
| preparation training product and get certified. Doing so | | | | necessary to deliver the project. They will also prove |
| will give you all the tools and techniques you'll need to | | | | the estimation techniques you have used, or suggest |
| manage your project's scope. In the meantime, here a | | | | corrections to them when they prove to be |
| few tips you can start using right away. | | | | inadequate. The work of these projects should never |
| Don't take the entire burden of curtailing project scope | | | | be wasted. The pilot should deliver a subset of |
| upon yourself. You share responsibility for this with | | | | functions for the planned system and the prototype |
| your project's executive sponsor and you won't be | | | | should be a base that the project can be built on. Build |
| able to control scope growth without their help. You | | | | the pilot or prototype into the overall project plan as |
| need their help with the Change Control Board (CCB) | | | | the first phase. Review the feasibility of the project |
| when senior stakeholders come to you with additions | | | | after this phase is over and re-calibrate your |
| to project scope which they believe have merit. It is up | | | | estimating methods if necessary. |
| to you to verify their business case and provide an | | | | Your first line of defense against budget and schedule |
| accurate cost estimate and it is up to the executive | | | | overruns on a software project is a well drafted |
| sponsor and CCB to reject the change. You'll help with | | | | Project Charter and/or preliminary Scope Statement. |
| this decision if you can manage to provide an accurate | | | | These documents don't have to contain a great deal |
| estimate of the additional time and money that the | | | | of detail, that's not their purpose, but do have to |
| change would cost. A finish date beyond what the | | | | contain a description of the system's functionality at a |
| organization finds acceptable or a budget increase | | | | high level. Don't try to make the documents detailed |
| beyond the organization's ability to pay will help the | | | | but do make them precise. Next, make sure you've |
| sponsor and CCB make the right decision. | | | | got all the right stakeholders and capture clear, concise |
| Be as specific as possible in the Project Charter, | | | | requirements. Use a pilot project to prove your |
| preliminary Scope Statement, or Statement of Work | | | | approach or a build a prototype to prove the |
| (SOW) as possible. The Project Charter and | | | | technology. In both cases you should re-calibrate your |
| preliminary Scope Statement will constitute the | | | | estimation technique if necessary and ensure that you |
| blueprints for the final product. Research usage of the | | | | have the right schedule and budget for the project. |
| software well before finalizing these documents so | | | | Your last line of defense is your executive sponsor. |
| that all the potential users, customers, or partners of | | | | The sponsor should be making the right calls on the |
| the tool are consulted and their requirements captured. | | | | proposed changes. Proposed changes that would |
| These documents should then become the | | | | increase the budget beyond the organization's ability to |
| benchmarks of your project's scope. New | | | | pay or extend the schedule beyond the time the |
| requirements that don't support the original intent should | | | | organization can afford to wait should be rejected. |
| be discouraged. Features or functions which would | | | | You can help by providing an accurate estimate of the |
| better support the original concept should be given | | | | cost of the change and the potential impact on the |
| serious consideration. Ones that add significantly to the | | | | schedule. One last piece of advice: whenever the |
| original scope should not. I regard a request to support | | | | scope of your project is changed, make very certain |
| a new category of users, or market, to the scope as | | | | that the new budget and schedule baselines are well |
| examples of requests for changes that are not | | | | communicated, then use them as your new baseline. |
| appropriate. | | | | |