What do you do when you discover that the scope creep on your project is coming primarily from one source?
We’re so accustomed to the warning signs of scope creep coming from the client side of the project. You know the drill: THEY can’t keep up; THEY don’t understand; THEY keep changing their minds; THEY, THEY, THEY …
True, when I managed projects, that is where I paid most attention to monitor and control scope. Stakeholders, and especially the fulltime client staff on the project, did not always understand why they could not keep asking for changes or new requirements on a whim.
However, scope creep is not solely defined in terms of uncontrolled changes to the approved requirements. And scope creep does not always emanate from the client. It can come from the IT team itself. For example, the IT team is “too cozy” with the client staff. Or, conversely, IT team members exhibit problematic behavior with the client staff. There is conflict within the IT team. The team is missing deadlines. They insulate themselves and operate in isolation. They communicate poorly.
Consider these in more detail:
- The IT team is “too cozy” with the client team. Normally, this is a good thing. Nothing is more conducive to a successful project than the IT team and client team working closely together to implement a new system. Until …
… until that camaraderie prompts unauthorized changes. You know the kind – those “small” changes that really “don’t need to go through change control”. Let’s just add a new report to help field managers with their weekly reporting. Or, what if we split that screen into three separate screens? Or, let’s just change these error messages to warnings instead.
These small changes seem innocent enough to the team on the ground doing the work, but they do not always realize the unintended consequences of their actions:
A new report? Sure, but how many hours will that take away from the scheduled tasks that must be completed? What about testing it, documenting it, implementing it?
Splitting a screen into three? Sure, but what if it is already signed off? What if downstream modules have already been tested and approved? What about retesting the functionality, redocumenting the specifications, and rewriting the training modules?
Downgrade error messages to warnings? Sure, but what if client management needed them to be errors? What will such a change do for end-user processing once implemented?
To prevent the kind of scope creep that can occur in these situations, the Project Manager must remind the teams early and often that there can be no variance from the approved specifications without formal change control. No matter how much their client “buddies” plead and coerce.
- The IT team is in conflict with the client team. This is NOT a good thing. Nothing is more indicative of an impending project failure than the IT team and client team constantly at odds with one another. Conflict can show itself in disagreements among the teams, lack of client cooperation, non-acceptance of deliverables, and even passive aggressive behavior that creates rework and delays.
Most of the time when I observed this behavior, it stemmed from the completely different working styles of IT and client staff. IT staff are trained to consider the schedule as pre-eminent. The project completes on time when all their tasks complete on time. Their next promotion is incumbent on their ability to deliver.
Client staff loaned to the project are not any less driven by deadlines – just not these deadlines. They are accustomed to performing well on their day jobs, but project work is often a foreign concept. They do not always respond timely. They are not as exact in specifying their requirements as IT needs them to be. They do not always understand how to use the tools that IT requires them to use.
And the frustration builds. I have witnessed analysts make assumptions about unclear requirements rather than dig deeper – just to stay on track. Or the developer that is an excellent developer, but should never be put into a client-facing situation. Or the team lead that was so exasperated with having to redo a deliverable that he put expletives in his draft PowerPoint slides and – you guessed it – missed one when he presented it formally to client management.
This is one of the people aspects of project delivery that Project Managers need to be attuned to. To prevent the kind of scope creep that can occur in these situations, the Project Manager should work with her team to understand that projects are not just process and technology. She needs to attend to the people aspects as well.
- There is conflict within the IT team. I remember the good old days when several of us would have heated debates about the best way to solve a problem on the project, and then grab a beer after work to enjoy our friendship. Such passion came from our desire to do what was right for the client and from creating a healthy work environment.
But there is an unhealthy conflict that can arise from an unhealthy work environment. When individuals allow their ego to get in the way of a better decision, refuse to take ownership for their failures, place blame on others, or take credit for another’s brilliant idea, conflict erupts. Such conflict can create an out of control situation in which discipline wanes and errors are introduced. Project scope increases as tasks must be redone and deadlines are missed.
This is another of the people aspects of project delivery that Project Managers need to be aware of. Conflict that is channeled appropriately is healthy conflict. But conflict left unchecked can create havoc. To prevent the kind of scope creep that can occur in these situations, the Project Manager needs to nip in the bud any such conflict before it spreads through the entire team.
- The IT team is missing its deadlines. The previous point discussed missed deadlines and added scope from inner-team conflict. But what about the team that just does not seem to care if they miss deadlines? They have their individual schedules, deadline dates, and estimated hours to complete their tasks, but they do not complete their tasks timely.
Whatever the underlying cause – apathy, procrastination, burnout, poor initial estimates, team conflicts, vague requirements – it is incumbent on the Project Manager to analyze the problem and solve it quickly. Missing deadlines is most often attributable to the people aspects of project delivery. To allow it to continue risks ultimate failure.
So often I have seen Project Managers make assumptions as to the root cause of the missed deadlines. However, this is a perfect opportunity to pause the project for a few hours and brainstorm with those working the tasks for their assessments. An incomplete understanding of the root cause leads to an incomplete resolution of the issues, and scope creep results.
- The IT teams are operating in isolation. An IT team is typically a cluster of several IT teams with specific responsibilities (e.g. functional development teams, infrastructure, technical architecture, system integration testing, and others) all working toward the same client objectives.
When individual teams go rogue and isolate themselves from the other teams (the usual reason given is the need to be heads-down to complete their tasks on schedule), the overall project becomes disconnected. Cross-team functional items are overlooked, errors are introduced, important information is missed; and the project begins to go off the rails. Scope creep is inevitable.
Such silos lead to dysfunction. Project Managers need to be aware of each team’s daily productivity to stop such dysfunction before it takes root. Again, it’s the people aspects that if left unchecked will take a project off track.
- IT team members communicate poorly. Or not at all.
Communication is the backbone of an IT team’s ability to deliver timely and within budget. Whether ignoring emails or missing meetings or not bringing issues to their leads, poor communication is another sign of the people aspects of project delivery gone awry. Poor communication inevitably leads to scope creep.
Project managers must spend time with their leads and project staff to instill the importance of communication among them. The need to help them understand the importance of the project to the client and the firm (or IT department if the project is internal), and why all forms of communication should be mastered and conducted professionally.
Situations such as these are project-killers. Scope creep can become scope gallop leading to project failure. An experienced Project Manager will recognize the signs of these dysfunctional behaviors early, and deal with them quickly and efficiently. More precisely, an experienced Project Manager will create a project environment that inhibits these situations from happening in the first place.
But should they begin to emerge, there are some actions that a Project Manager can take to mitigate them:
- monitor the behaviors and work ethic of team members, watching for signs of unhealthy actions that can ultimately lead to scope creep (we had a name for this when I started my career – MBWA, Management by Walking around),
- call out team members for detrimental behavior and demand they immediately stop,
- confront conflict when it happens, whether internally or with members of the client team, and promote a cooperative work environment,
- break up siloed behaviors and encourage inter- and intra-team communication,
- model good communication and provide instruction in areas where team members may be lacking in their communication skills,
- remove consistently poor performers and those unwilling to change their destructive behaviors from the project so that good performers are not de-motivated,
- monitor work effort of the team to avoid long periods of excessive overtime which can lead to poor morale and inferior results,
- conduct regular team meetings to provide status and to receive team members’ feedback on the inner workings of the project, and
- conduct off-site, morale boosting activities to encourage team bonding and camaraderie among team members.
And one more thing…
Project Managers should encourage their teams to keep an eye on them. Project Managers are not immune to creating scope creep without even realizing it. Their team members should feel free to call them on it, especially as it will impact their scheduled tasks at some point.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.