Welcome to part two of the five- part series on how to best use the Small Project Management Guide. Here is Andy’s question to kick off the discussion:
One of my favorite phrases in project management is “Scope Creep.” It sounds cool, but it’s not. It’s awful. Got examples?
A simple definition of project scope is all the activities that go into creating the project product. It is a description of the actual work that will be performed by the project team (product scope) and the project manager (project scope). Good scope management is especially key to your small project because most small projects have severe time constraints, resource constraints, and, often, part-time project team members.
That is why the Scope Statement template starts by having you list the customer’s requirements for the project product. Strive for specific and detailed requirements from your customer. A useful technique is to have the client come to this meeting with examples of other projects and features they want in their project product. Continually stress to the project customer that the requirements are also the conditions of satisfaction that have to be met in order for the customer to accept the project product.
The next two parts of the template are self-explanatory and vital. How much time do you have and how much of a budget do you have has to be realistic in light of the customer requirements. In the initial excitement of a fresh new project people tend to be overly-optimistic about costs and time so it might be good to develop an optimistic estimate, a pessimistic estimate, and a realistic estimate. Average the three and you will probably be close to the actual budget and schedule. For larger projects there are a multitude of techniques and software to better estimate schedule and budget but this should suffice for small projects. (A little aside here: open-source does not mean completely free. There are costs in the form of equipment, people’s time, and possible programming modifications. I often see customers who think that if you substitute open-source, you don’t need a budget. It may be cheaper than proprietary software but there are still some costs.)
The last part of the template is where we get to Andy’s question on scope creep. Now it seems counter-intuitive to list what is not in the project but I put that there to start the conversation on what the project boundaries are in terms of work. As the project progresses it is inevitable that the customer will think of a new feature or requirement for the project. These suggestions are typically accompanied by an observation on how simple it should be to implement the suggestion.
Not really. As the number of project tasks increase so does the interdependencies among tasks, the drain on resources, and the impacts on time and budget. As more of these suggestions creep into your scope the project starts to slip behind and goes over-budget. I’m not saying to ignore all suggestions from the customer. But before incorporating the suggestion into the scope, analyze the impact that the suggestion will have on the project and then communicate this to the customer. If they are willing to pay extra and to accept later deadlines then go ahead and incorporate the suggestion. It is also a good idea to discuss a formal change process with the client during the planning phase so that they will think twice before making suggestions.
Let me give a non-IT example. IT projects have a number of methods for dealing with scope creep and IT project products can be iterative. A better example of the dangers of scope creep is with projects that have to deliver a completely finalized product.
In 2008, I was the technical lead on a project to hold an international academic conference on the subject of intercultural communication. I was in charge of the website, creating and publishing the conference program, and handling the audio-visual requirements for the presentations. As time went on, I experienced project scope creep in that my list of responsibilities increased to include volunteer recruitment, vendor relations, and therapist.
There were numerous examples of product scope creep but the one that stands out is the creation and publishing of the conference program. I was allowed to recruit a graduate student who had superb graphic design skills to put together the program. In January of 2008 we were told we needed the final program at the end of July well in time before the October conference. The actual delivery of the final program was mid-September because:
- Without consulting anyone else, the co-chair decided to extend the proposals deadline to July. That meant we did not have a final schedule of sessions until early August.
- The other co-chair continually insisted we slip-in last minute sessions and participants “as a personal favor to him.”
- Constant and contradictory design suggestions for the conference program. We had a design committee that was to be the official communication channel but our conference chairs would solicit suggestions from anyone whether they were connected to the conference or not.
A close second to the conference program scope creep was the AV requirements that continually changed during the conference. The original plan was to finalize the AV needs in August so that we had plenty of lead time to track down projectors, sound systems, and miscellaneous equipment. No such luck as participants waited until the day before the conference to inform me of what they needed. My favorite example was the second day of the conference when I had to track down and rent the sound equipment for a Japanese jazz combo. They had casually mentioned their needs to me at breakfast that morning and needed the equipment by 5:00 PM that evening. And pop goes the budget.
Change is inevitable but the best thing you can do for the project, your customer, and yourself is to have a consistent process to handle change. Establish your project scope so that you can better understand how the proposed change will impact your project and make sure your customer understands the full impact of their suggestions. It is good to be attentive to the customer’s needs but your primary goal should be delivery of the project product that satisfies all of your customer’s requirements.
In part three, we will discuss how to best break down and plan project tasks. Thank you for using the Small Project Management Guide.
Another great post with great tips and examples. I appreciate the reference to graphic designers. Oh the stories I could tell…I’d actually never heard it termed “scope creep” but I have witnessed/experienced the phenomenon quite a lot in the design world. It is literally the bane of every designers existence, I can tell you that much.
Also, good call with the oss. People seem to always associate oss with being completely free which is simply not true. It does have the potential to be completely free, but how often is that really the case? There will be additional costs.
@Jeff – Thank you! Scope creep is the bane of the project manager and the project team. I bet some of your stories involve people sneaking around the project manager and going directly to the team member. “Let’s just keep it our secret,” he or she will say and then bribe the team member with cookies. What do they bribe graphic designers with?
The OSS was in my mind due to a current project I am on. We have a group arguing for Sharepoint, a group arguing for Drupal, and a group arguing for Alfresco so you can imagine all of the “cost estimates” I have seen from all sides.
@Bill. These are a great series of posts and very important lessons.
Once you are done, please make a final post with links to each of these posts about using the Small Project Management Guide. I’d like to post it on my blog, All Things Sterling.
@Sterling – Thank you! I will be glad to create the final post as you suggested. Do check with Steve also because I gave the guide to GovLoop so it is their property.