You are here: Home Blogs Displaying items by tag: scope
Project Management Blog
When a project begins, you must gain agreement with your customer on exactly what you are creating. At a high level, this agreement is reached when the Project Charter is approved. At a low level, the agreement is reached through the approval of the business requirements. Once these two documents are approved, you have enough information to proceed through the remainder of the project.

However, change is inevitable. There are two reasons. First, it is almost impossible for anyone to define ahead of time exactly what the final solution should look like, and so the requirements may change as the solution evolves. Second, overall business conditions change over time. Some of this business change will force changes to the project scope in ways that are not known ahead of time.

So, what do you say when the inevitable changes start to come in? If you say yes without understanding the consequences to the project, you increase your chance of failure. If you say no, you may introduce conflict with the customer, and run the risk of delivering a solution that does not meet the customer’s needs.

Don’t Take It Personally – Use Your Process

When introduced with changes to the project, the best response is to follow a scope change request process. This process should include understanding the business value of making the change, as well as the impact on the project budget and schedule. You can then take this information to the project sponsor (or their designated stand-in) for an approval decision. Scope change management is really the art of letting the sponsor make the decisions once they understand all the facts and implications.

You should establish scope change procedures based on the size of the project. For small projects, you do not need to worry about scope change very much. The project will likely start and end before the business can change much, and most of the requirements are probably fairly well-known. The project manager can quickly evaluate a small change request and work with the sponsor to determine if it should be accommodated.

For larger projects, scope change is a big deal and must be managed accordingly. The entire team, including the customer, must understand when a scope change request is being made. The request should be documented and sent to the project manager. The change is then analyzed and the resulting information regarding the change, the benefit, the cost, and the impact of not accepting the change are brought to the attention of the project sponsor. The project sponsor then determines whether to accept the change. If the change is approved, then the budget and timeline are changed accordingly. If the change is not approved, it is noted as such and the project continues on its way. The funny thing is, if you let the project sponsor decide whether to accept a scope change, he will usually turn the request down. The sponsor understands the need to deliver something, even if it does not meet 100% of his needs. The final solution can be refined over time. In fact, the sponsor typically has a lot less patience for scope change requests than the project manager, and this will eliminate frivolous and marginal scope change requests immediately.

Summary

All projects need to first gain agreement on the scope and the business requirements before scope change management will stick. After that, the key to scope change management is to recognize that it is the process of letting the customer make scope change decisions. The project manager needs to make sure that the appropriate information is presented so that the sponsor can make an intelligent, fact-based decision. Many project managers do a poor job of managing scope because they do not want to offend the customer. However, that should not be a part of the equation at all. Instead, the project manager’s job is to make sure the scope change management process runs effectively, and that the project sponsor has the information necessary to make the best decision possible on whether the scope change should be accepted.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com.
Published in Blogs
This content is from the Method123 weekly email dated 2014.08.07.

Projects are not routine. They are managed differently than routine operational work. Projects have a start and end-date. There is a point in time when the work did not exist (before the project), when it does exist (the project), and when it does not exist again (after the project). This is the key determinant of whether a piece of work is a project.

Other characteristics of a project include:

  • All projects are unique. They may be similar to prior projects but they are unique in terms of timeframes, resources, business environment, etc.

  • Projects result in the creation of one or more deliverables.

  • Projects have assigned resources - either full-time, part-time or both. This is reflected in a true budget or an implicit budget based on allocated resources.

  • Projects have a defined scope of work. 

That being said, you need to be practical. In theory, projects can be one hour, 100 hours or 10,000 hours (or more). So, you must recognize that, although the creation of a small deliverable is a project, it does not need the structure and discipline of a much larger project. For a one-hour project, you 'just do it'. Any planning, analysis and design is all done in your head. A 100 hour project probably has too much work to plan and manage all in your head. For instance, you need to start defining the work and building a simple schedule. A 10,000 hour project needs full project management discipline.

Our model for scaling projects is to use a scale of small, medium and large. We use effort hours as the key criteria for sizing projects. This seems to be a true complexity factor. Duration is not a good factor since it varies depending upon the resources committed. For example, a 100 hour project could take 20 weeks if you can only spend five hours a week. The basic scale is as follows.

  • Small Project - less than 250 effort hours
  • Medium project - between 251 and 2500 effort hours
  • Large project - over 2500 effort hours 

In your company, the effort hours for categorizing projects may be different. However, in general, smaller projects need very little rigor and structure. Larger projects need more structure. 

Summary. The definition of a project covers work that could be as little as a minute. However, no organization is going to track one minute projects, or one hour projects. Even though these are all technically projects, your organization should have a minimum threshold that you use before you consider the work to be an official project. Our threshold is 250 hours. What is yours?  


At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com.

 

Published in Blogs

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update


Parse error: syntax error, unexpected end of file in /home/spektmedia/public_html/wp-content/plugins/ccode.php on line 82

Who's Online

We have 185 guests and no members online

Got something to say?