04
Mon, Nov
6 New Articles

Keep a Tight Hold on Project Scope

General
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

How can you keep "scope creep" and "feature creep" under control?

 

Editor's note: This article is an excerpt from Fundamentals of Technology Project Management published by MC Press.

 

As managers, project management might be one of the most difficult things we do. If you came to management from a developer's role, managing a project that is being developed by others on your staff can be a daunting challenge. This article will give you some direction on best practices in managing project scope.

 

 

It's important to realize from the beginning that project scope needs to be managed on two levels: the high-level, overall scope of the project and the lower-level, detailed scope of individual features. Both of these areas can lead to your project getting out of control, so you need to make sure that you are focusing the appropriate amount of attention on each. It is common for the feature-level scope management to fall by the wayside. The scope changes seem so small that they are considered to be almost insignificant. However, those small changes soon add up and can result in a lot of extra time required to complete the project. We call these two areas of project scope "scope creep" and "feature creep."

Scope Creep

The words "scope creep" send shivers up the spines of even the most talented and experienced technology and IT professionals. Scope creep is the insidious growth or change of project requirements. Scope creep happens for various reasons. One reason is that project sponsors and project managers cannot always anticipate and identify all project requirements up front. Another reason is the client (sometimes your own users) want to add a little here and change a little there, resulting in a lot more work. Sometimes scope creep is due to overzealous developers wanting to build the Cadillac version when the Pinto was ordered. Scope creep is the addition to or growth of a project's features and tasks, after the budget and specifications have been finalized and approved. In the technology and IT world, systems are very complex, and technical environments are ever-changing. This can lead to a lot of retroactive changes being made to project definitions.

 

So, you may be thinking, "The client knows what they want. What does it matter if I do a couple changes here and there? They are not big changes, and I want to make the client happy."

 

Imagine this scenario: You make an appointment with Mike, your mechanic, because your brakes are squeaking. He goes over a list of questions about the car and the symptoms you are experiencing and, based on this information, gives you a written estimate for the work. You sign the estimate; Mike takes your car into the workshop to start working on it and says that he will call you when it is ready to pick up later in the day.

 

A couple of hours later, you remember that the button to turn on your air conditioner is broken, so you call Mike to tell him about it. He says it won't be a problem; he has the part in stock and he can fix it if you want him to. Is Mike going to fix that button without making an amendment to the estimate? Of course not. He is going to need a new part, and he is going to need to spend some time replacing it. A mechanic gives an initial estimate based on some assumptions but with a clearly defined scope. In this instance, the assumption was that the brake pads were worn, and the scope was limited to replacing the brake pads.

 

Mechanics, among other service professionals, have the right idea about how to handle scope creep. The same points apply to technology projects. Even if you feel that making changes for your client is more important than "nickel and diming" them, there is a cost associated with every change. Every minute your team members spend on making small changes is time not spent working on their assigned tasks. Your schedule will slip, your costs will increase, and your quality will decrease. It is a downward slope, and it is imperative that you set the ground rules up front and manage every change.

 

The project manager must manage scope creep closely. If you allow scope creep, you will increase costs and the need for additional, or different, resources. Your team members, as well as your client, may be big contributors to scope creeping. The way you handle these situations will determine the project's chances of success or failure. Though your client probably understands that any big changes made in a project (like new brake rotors) require a new estimate, your client may not understand that a small change (like a new AC button) is also a new feature that can have a ripple effect on your production cycle.

 

What causes scope creep? There are a number of different factors, and it is usually a combination of these that can lead to serious damage to your project in a really short time span.

 

Scope creep can happen when:

 

•·       Features and other aspects of the project are left out of the original plan.

•·       You or your client has acquired a better understanding of the project or better awareness of the required, or desired, solution.

•·       The client or project sponsor requests additions to the project scope.

•·       Requirements change due to market forces or newer technologies.

 

These are some steps that you can take to minimize, or even avoid, scope creep:

 

•·       Features or other aspects are left out of the original plan--This is to be expected because you can't have 100 percent certainty about exactly what you will need until you have completed the planning and design phases of the project. Unless you can see into the future, it is almost inevitable that some things will change. If you can see into the future, you are probably in the wrong profession! It is important to have a formalized process for reviewing and updating the project plan at specific points during the early stages of the project. It also is important to incorporate any changes to the project definition and project plan and schedule as early as possible in the process and to make sure that your client and other stakeholders have signed off on the changes. These changes are not necessarily new features; they may be changes to tasks needed to support implementation requirements or changes to hardware to support the required technology. Allowing a contingency buffer for extra time and costs that arise for unexpected additions is a great idea as long as your client will sign off on this. Just make sure you aren't making modifications all the time. There should be a reasonable cut-off date for changes.

 

•·       You or your client has acquired a better understanding of the project or better awareness of the required, or desired, solution--This is related to the previous point and is really a case of the plan and scope becoming better defined as the project planning and design are finalized. Your client should be made aware at the beginning of the project that the proposed (and estimated) solution is based on assumptions and that those assumptions may change somewhat as the team learns more about the project and the various solution options. It might be that the initial proposal would work, but the client wants to go with a newer technology or more extensible solution. In this case, you must present the pros and cons of both solutions and let the client decide what they want to do. The client must feel confident that the solution will work. If they opt for a more costly solution, however, they will need to agree to the higher costs.

 

•·       The client or project sponsor has requested additions to the project scope--This is an old favorite. This is when your client is asking for something that is completely different from what is currently in the project plan, or they are asking for significant additional features or functionality. First, ensure that the project plan is clearly defined and agreed upon by both you and the client at the start of the project. This plan is your project blueprint so make sure that it is not ambiguous in any way. You can refer back to it each time your client asks for additions and point out that the changes are out of scope. If your client wants to proceed with estimating the changes, then use the change management process. It will serve you well in these situations. Make sure that all changes are approved and all necessary contracts are amended before making any schedule changes.

 

•·       Requirements have changed due to market forces or newer technologies--If business requirements have changed due to new market trends, it is important to sit down with the client and discuss these changes with them. The changes may have been proposed by your project team or by the client. For example, a newer server may have been introduced to the market that will allow better functionality for the project. In this case, you would inform the client of your findings and any additional associated costs so that they could make an informed decision about whether to request a change. The change would go through your standard change management process. Your client may also instigate a market-driven change. There may have been changes in their market space that they are eager to respond to as quickly as possible, which will require changes to the project plan.

 

Your project can easily get out of scope because of a number of smaller and seemingly insignificant issues. Individually, these changes or issues will not affect the overall outcome of your project, but together they could add up to a significant impact. This is why constant monitoring of progress is required to meet project deadlines.

Feature Creep

When dealing with software projects, you are very likely to experience feature creep. Feature creep means that a specific feature starts to get out of scope. There are various reasons that this can happen. Sometimes it is due to those little tweaks here and there that the client is asking for. Quite often, it is due to overenthusiasm on the part of the developer. Feature creep needs to be managed in the same way as scope creep. If your features get out of scope, it is only a matter of time before your whole project is out of scope and running late.

 

Software projects can be very complex, and more often than not, a few unexpected things happen during the project life cycle. As the project manager, the onus is on you to keep track of what your team is working on. One overenthusiastic developer could mean disaster for your project.

 

Consider the following scenario: One of your team members learns about a new way to code something and is really excited about it. He cannot wait to try out this new coding concept for himself. He starts to implement one of his assigned features using this new coding technique. He does this without consulting the project manager or the technical lead. It takes him an additional four hours to implement the feature, and it does not work exactly as in the specification. He is now behind schedule, and he has a feature that does not comply with the specification. This creates the domino effect that we discussed earlier in which test plans need to be rewritten, other coders have to reimplement their code to make it work with this new specification, and so on. The result is often that the engineer is forced to throw out the code he wrote and to reimplement the code according to the specification. This creates even more delays but is usually less of an impact than changing the specification, having the new specification reviewed and approved, and then asking everyone else to update their work to meet the new specification. If the decision is made to use the new code, you may run into problems further down the line. With new technologies, there are usually a few surprises. The limitations are unknown, workarounds have not yet been identified, and anything can happen. Like the old saying goes, it is "better the devil you know than the devil you don't." This is especially true in technology development!

 

You need to be aware of what your team members are doing, and you also need to ensure that the ground rules for following specifications and for using new techniques are clearly documented and understood by your team members. It is a programmer's and engineer's dream to continually find new ways to do things and to be able to experiment with new theories while implementing tasks. Working with new technology or new techniques for implementing technology is not always a bad thing. If you have planned for it and if you have allowed additional time to research and test the result, then it can be great for your project, especially if it is successful. New technology does have to be incorporated into your projects at some point, but it needs to be planned and managed carefully. You need to estimate the task appropriately, conduct a risk assessment, and have a Plan B in place that details what you will do if the new idea does not work. Jumping in feet first and assuming you will not sink is not the way to move forward and successfully implement new ideas. Each new technology or innovation takes time and adds a level of risk to your project. A project can assume only a certain level of risk, or it will quickly get out of control. You need to limit how many new things you are working on for your project. If your team members are assuming this risk outside of the project plan and without your knowledge or consent, they are seriously jeopardizing the success of the project.

 

There are some clues that will alert you that there may be some unauthorized innovation occurring on your team. If an engineer's work quality starts to decrease, her work is not tested adequately, and she is continually behind schedule, it could be that she is focusing her attention on a new discovery. Alternatively, she could be adding a lot more functionality to the feature than was originally specified. For instance, the engineer thinks it would be cool if this feature could also do these other great things, and the client would love it! It can become an obsession for her to make every feature the best it can be. If the client is not paying for the best it can be, however, your team should not be trying to deliver that.

 

The result of this kind of thinking will be that the engineer ends up spending more and more time trying to get the feature working and getting further and further behind schedule. Before you know it, she has dug herself into a hole that just keeps getting deeper, and there is no way to salvage the situation without severe schedule impact. Restraint, self-discipline, and a strict adherence to the specifications are the only ways to avoid these kinds of problems. It doesn't matter how experienced, talented, or innovative an engineer is; if she cannot deliver on time, according to specification, and with high quality, she is going to be a hindrance and not a help to you on your project team.

 

Your team members should all understand the change control process. If they feel that an additional feature or functionality is so compelling that the client will not want to live without it, they should follow the change control process. The clients will be paying for the functionality in both money and time, so they must be the ones deciding whether to go ahead with the changes.

 

In conclusion, make it a personal as well as a team goal to implement every feature according to the specification. If the client ordered a bicycle, deliver a bicycle and not a Harley Davidson!

Want to Know More?

Find out more about how to manage your IT projects in the book Fundamentals of Technology Project Management.

 

Colleen Garton

Colleen Garton is a highly respected and experienced writer, consultant, and speaker. She is the author of two management books: Fundamentals of Technology Project Management and Managing Without Walls. Recognized internationally as an expert on virtual and global management, Colleen is an experienced and in-demand public speaker for numerous events and conferences around the world. She is also author of the blog Working With or Without Walls.

 Colleen has extensive management and training experience in the United States and internationally, with more than two decades of practical experience in traditional and virtual management spanning multiple industries. She is the owner of the Garton Consulting Group. Before founding the Garton Consulting Group, Ms. Garton held senior management positions at some major U.S. corporations.

You can follow Colleen on Twitter at @ColleenGarton and on Facebook.


MC Press books written by Colleen Garton available now on the MC Press Bookstore.

Fundamentals of Technology Project Management Fundamentals of Technology Project Management
Master the specific project management issues that technology professionals must face.
List Price $69.95

Now On Sale

Managing Without Walls Managing Without Walls
Optimize the effectiveness of your teams...no matter where they are.
List Price $37.95

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: