Scope Creep: the Good, the Bad, the Ugly

As digital project managers, we all know it and we all dread it, but working in the digital space makes us especially prone to scope creep. Regardless of their best intentions, clients will always try to expand on the original features of the project; whether it’s a small request or a large one, we all know it is bound to happen.  While my immediate reaction is to go on the defensive against scope creep, I’ve learned that managing it can take on different forms in different circumstances. So I’m going to take a look at the good, the bad and the ugly of scope creep.

I’m sure you find yourself thinking: “There’s good news?” There can be. We can all admit that scope creep is inevitable in the fluid and dynamic digital space. However, as a mobile PM at CrowdTorch, I’ve experienced several instances when client feature requests have resulted in platform fixes and improvements, and even helped expedite road-mapped features. If addressed quickly and managed appropriately, scope creep can shed light on product issues and introduce opportunity for improvement. Additionally, when expectations are solidified at project outset, scope creep can open up consultative lines of communication with clients and create a more collaborative working relationship. So while we all probably see scope creep as an inherent negative, sometimes positives can be gleaned from client overreach.

But let’s face it, we all think of scope creep as a badthing. While there is the potential for it to unearth better solutions, there is greater potential for it to adversely affect the project. As PMs, project milestones are one of our biggest drivers, and timelines are usually the initial fallout when scope creep enters the picture. However, clients are often sensitive to timelines as well, so use that to your advantage first. Manage client requests by couching their desires in terms of timing: “We’d be happy to explore the possibility of building a rate calculator, but that will push the delivery date back about three weeks.” When time is of value to the client, you won’t have to do much to make them reconsider.

If client expectations aren’t managed early on, scope creep can also result in bloated expectations and client entitlement to project expansion. When you acquiesce to a client request at the beginning of the project, you’re at risk of perpetuating that type of behavior throughout the project. Setting a strong precedent at project kickoff and establishing solid timelines and defined scope will help allay client overreach going forward. In most cases, scope creep is detrimental to the project lifecycle and results in the need for additional management time to get the project back on track. Early detection of the creep helps contain it and can still result in fostering a collaborative relationship with clients as you pose solutions within the initial scope.

Pardon my pessimism (or realism), but oftentimes scope creep can get ugly. Newsflash – clients aren’t always right. Client requests don’t always result in overall product improvement. As PMs, we not only manage the client relationship and keep it intact, but we also manage the process of working with internal development teams to determine what requests and features would actually provide value to the client and the product line as a whole. When you get into a situation of severe scope creep, it not only affects the client relationship and project milestones, but can also create a ripple effect throughout your product line and organization as it derails other projects and affects internal development queues. We all know happy developers make for happy projects, and all too often scope creep results in grumpy devs.

Then there is always the obvious budget issue. Additional scope not only overreaches the project budget, but also drains PM and development time, which takes away from other revenue-driving project initiatives.

In conclusion, scope creep isn’t always a bad thing. Get out in front of it by setting solid expectations and open communication channels at project outset. When you sense the creep, try to manage it to the advantage of yourself as a PM, your client and your company. In my experience, the effect of scope creep is also very client dependent. Establish that deep, collaborative relationship with your client early on, so you can steer it in a cooperative direction throughout the project lifecycle.

Done is a Moving Target

“You buy furniture. You tell yourself, this is the last sofa I will ever need in my life.”

What I love about this quote from Chuck Palahniuk’s Fight Club is not the nihilistic and decidedly anti-capitalist overtones, but the light that it shines on our incessant, yet well intentioned, need as human beings to feel like something is “Done.”

While it’s perfectly natural and healthy to strive toward an objective, it can be equally dangerous and destructive to have an unreasonable expectation about that goal. And the easiest (“slash” most threatening) expectation one can have is that “Done” is a finite thing.

Moreover (and more usefully), though it often means breaking some widely held and deeply rooted communication patterns, re-shaping the dialogue around what “Done” is can lead to stronger projects, products, and partners.

Most Projects Are Never “Done”…

It’s an unnerving thought, but a reality. Let’s apply this idea to custom software and websites, though the principles extend to nearly any type of project. Have you ever experienced any of these scenarios following a project’s “completion”…?

1. A product or service changes, requiring a complete overhaul of the app’s user experience workflow.
2. An opportunity in the website’s competitive landscape necessitates the incorporation of a new user persona and, in kind, an entirely new marketing strategy to drive conversions.
3. A great new widget, wiki or web integration is released that might really move the needle on customer interaction within the website.
4. A security patch is strongly encouraged by the open-source community for the framework upon which your app is built.

…And Success is Almost Never “Achieved”…

If only(!) we could rest on our laurels after having reached our initial metrics of success… Unfortunately, the truth about success is far more complicated:

1. Goals may need to change before they’re even reached.
2. Goals may be have been set poorly in the first place, and are either too easily or unreasonably attained.
3. And even when a goal is reached, a new objective must take its place for any business or team to keep moving.

So How Should We Speak About “Done”?

Though these are not striking or shocking ideas to anyone (especially those who have ever worked in technology), it’s easy to perpetuate the misleading idea that there is such a thing as capital-D “Done.”

Which is why re-framing the conversation, and the vocabulary, around these projects can lead to more honest and realistic collaboration.

Discuss “Iterations” and “Phases” Rather Than “Completion”

Though a launch date or other significant (and impending!) milestone exists, don’t let it become a watershed moment. Plot out phases, releases, and their relevant deliverables on a calendar in advance of “the big day."

This helps ensure more seamless deployment from an engineering perspective, while helping all of the stakeholders involved to distribute the communication of desired revisions and polishes — rather than trying to cram them all in during a mad scramble toward launch.

Use Prioritization and The Icebox

New features? Revised features? Nice-to-haves, but lacking the budget right now? Product owners and developers alike will likely come up with a slew of ideas throughout the development process: but that doesn’t mean they all share the same priority. Some ideas might even sit in The Icebox for a while until budget or business value allows for them to thaw out and get built.

The important thing is to have a dialogue around when (priority) and why (business value)rather than all or nothing (i.e. “Done”). Agile Scrum and Kanban methodologies are great ways to help rank the importance and order of what gets delivered and when, but they’re far from the only ways to accomplish this.

Display Evolving Indicators

Most importantly, how can you communicate phases of “Done” on a timeline? How can you visually indicate progress, anticipated delivery, and budget in a way that communicates which work is executed and when?

How can you display non-phase-critical tasks or features on a timeline? And what kind of mental and emotional relief might that help provide your stakeholders and product owner, to show that they’re all well accounted for and considered?

The right project dashboard and reports not only eliminate misconceptions of the mythical “Done”, they can help drive much more focused work and collaboration.

Conclusion

No project succeeds without goals, and these goals should be communicated and familiar to everyone involved. By taking the time, though, to re-align everyone to a common idea of “Done”, you and your team will be better equipped to reach them.

**Note: All of these thoughts subject to change.

Chris Walker is a Project Manager at Astonish Design in Austin. After several years of experience in the hotel and tourism industry, Chris brings a unique sense of service and hospitality to his role as a PM. Originally from Texas, his love for film and travel led him from small towns to larger cities (and their cinemas), eventually driving him to the University of Texas at Austin where he studied radio-television-film. Now he’s able to use those well-honed storytelling sensibilities — committed characters, epic quests, and happy endings — to help ensure successful project execution.

My Team is the A Team

…And I’m always Hannibal

I think it’s impossible not to work closely with other people and not draw comparisons to how between your team and other teams, fictional or otherwise.

My group of friends is constantly making comparisons between our dynamic and that of the characters in the Always Sunny crew (surprisingly, I am not always Sweet Dee), and my college girlfriends have made analogies between us and the Sex and the City cast on more occasions than I would like to admit.

It makes sense then, that I have the same habit with my team at Design For Use. Our core team is small, comprised of me as the Project Manager, Valle as the User Researcher, Natalia as an Interaction Designer, and Young as a Senior UX Designer.

Just given our basic positions in the company, and having no context for our personalities, I’m sure it’s easy to make some assumptions about our role on the team: As PM I’m the mother figure, Valle (Researcher) is the straight guy, Natalia (Designer) is the free spirit, Young (Sr. Designer) wild man.

The A Team Breakdown

However, that’s not at all the case. The great thing about our team is that depending on the scenario, each of us has the ability (and tendency) to take on different roles depending on what’s required of us.

Therefore, I think the best possible comparison between my team and any other existing team in history is the A Team.

The most typical way our roles align with the A Team is as follows:

Project Manager as Hannibal

Not surprisingly, I am oft the leader of the group. I mean, part of my job description entails his tag line “I love it when a plan comes together.” When I get “on the jazz,” that means I’m going out on a limb for the client or the project.

User Researcher as Face

Valle is most often the Face of the team. She is known for forging the initial (and crucial) relationships with the clients because she leads our contextual inquiries and stakeholder interviews. Everyone always loves Valle. She ends up getting to know our clients early, and then serves as our “woman on the inside” when we need information from the client. The fact that she’s easy on the eyes doesn’t hurt.

Interaction Designer as BA

Natalia might not seem like a natural fit as a stand-in for Mr. T, but she is. Most of the time. She is like a Mrs. Fix It who can do pretty much anything for our team or the clients. Most telling in her comparison to BA is her soft core despite her tough exterior. While Natalia doesn’t fly into fits of rage over design reviews or client requests, I have heard her mutter “you better cut that jibber jabber” when we get off topic during a review.

Senior UX Designer as Murdock

While we’ve never had to spring Young out of a mental hospital, he is definitely the loose canon of the team. He will stop at nothing to make sure that his designs make an impression for our clients. I never know what is going to come out of his mouth next. It keeps things interesting. You can also easily draw a parallel between Murdock being the pilot of the A Team and Young being the pilot of our design direction.

However, sometimes we swap roles. Sometimes when we’re dealing with a difficult request from a client, Natalia becomes Face, Valle takes on Murdock, and Young is BA. But I am always, always Hannibal. Although I may not always have a cigar in my mouth, I am typically thinking of new tactics and approaches to solve a problem.

While there are times when Valle might pull a BA because we’re not keeping in line with user needs and goals. And Natalia might go Murdock on the client because she believes so wholly in her designs. And even Young has occasion to turn into Face for the right client and the right circumstance. But again, there I am as Hannibal, blowing smoke rings in the back of the room and plotting our next move.

I really DO love it when a plan comes together.