90 Percent

Project management, productivity, change management, and more!


Leave a comment

What’s scope creep and tips to avoid it | Part 2


Source: grietgriet

Scope creep is a very important subject, something every project manager is challenged with.

In my previous article What’s scope creep and tips to avoid it, I listed a few tips to help people face those challenges, and that article was very popular, so I thought it would be great to add more to it and focus on the team:

Scope creep can be 100% an internal issue, so watch out!

Often we are under the impression that scope screep is something we forgot, or something the client asks for and we have no choice but to accept for whatever reason. But, you know what? Sometimes, it’s simply an internal thing.

Often, what will happen is that scope is defined in a certain why, and then, from there, you will create the estimate, and work will get started. Everything goes well, and as you discuss with team members, they sometimes casually mention some stuff like “Yeah once that is done, we’ll need ‘this’ done and then we’re good” or “we need this because we have ‘this’ and ‘this’ to do”… All the while in your mind you are telling yourself: Where does this all come from?

The reality is, no every team member will be “connected” to the budget as you are as a project manager. This is completely normal because they are focused on their own role and you should be focused on yours. The impact of this is some small tasks (or bigger) will be neglected in the documentation or even in the estimate but here and there you will find out that it MUST be done.

Why? Well, it varies; it could be a client expectation not shared with you, it could be a technical requirement mentioned absolutely nowhere…Or something else!

Regardless, this is tricky, but there are things you can do to help prevent this!

Focus on the long term

So, when it happens and you are “stuck” with the request, you may think this is the end of the world, your project is going bad because of it, and nothing can be done; whether this is true or not for your current project, you can focus on the long-term, which are your future projects. How? Well, by discussing a specific issue and adjusting for the future.

For example, if client expectations around different deliverables were not clear and were “implied” somewhere, talk to the person responsible of managing the client and explain the impact of those expectations being “hidden” from you. The thing is, that team member may have the best intentions in the world towards the client, but he may not realize the impact of the added work. So, the best way to make him understand is to explain gently to him the impact by showing underage caused by the added work he didn’t share in the beginning.

Manage team expectations

We’re always talking about managing the client’s expectations, but what about the team’s expectations? There is absolutely nothing wrong with telling team members that anything other than what’s inside the estimate will NOT be done so “be careful”.

However, it’s very important to consider that whatever you say “will not be done” may be an absolute “must” to your project. This means you have to use a specific vocabulary with your team.

Try using:

  • Are you sure we included everything we need for the project?
  • This here is what we’ll be doing, we won’t be able to afford anything else, are you sure it’s accurate?
  • Are any other client expectations forgotten here?


  • We won’t allow anything else than what’s included here
    • what may happen is that some “things” will come up that will literally prevent your project from being functional if it’s not done and you won’t be able to tell your client you “forgot” this
  • Saying nothing
    • people may think whatever they are holding back is “implied” in the documents

Manage team expectations… again!

Repeating myself? Well there is more to it than what’s above!

Scope creep can surprisingly be with team members spending more time on certain tasks because they thought they could so they made the design or the feature “more awesome”. It could be considered gold plating in a way.

You have a tight budget? Poor or no contingency? Well, tell your team! As much as they are not “budget focused” as you are, if they are remotely committed to the project’s well-being, if they understand the budget being tight or being in a horrible shape, there is nothing wrong with letting them know and reaching for their cooperation.

This will have a huge effect on how they make decisions or how they plan their work.

For example, a designer may take less time to search for a “miracle” image for his design and settle for one that’s just plain great. A developer may take half the time to code a certain feature because he’ll plan his code a different way.

Regardless, your team must know the situation and they will take it into consideration before taking more time than planned to do the work.

In conclusion

As you can see, the way you communicate with the team can have a tremendous impact on how scope creep affects your projects. Take the extra time to your team members, even if it’s too late for this project, it may be very positive for future projects.

6S Bubble

Leave a comment

6S for success!

6S for success!
By Cécile Bérubé, PMP

6S BubbleManaging projects is like riding a bike. At the beginning, we hold the handles tightly, afraid of falling. Then, we learn to let go and ride our bike looking ahead while pedaling.

Putting down and controlling all requirements up front, holding on the handles tightly, having stakeholders clearly explain the product objectives solely via requirements is not efficient.

Learn to let go. Building user stories, rather than hammering out all requirements up front is easier to manage with the End Users. It’s tangible and expectations are easier to communicate. Tools are available to facilitate discussions (ex: diagrams, models, prototypes, storyboards).

Poor requirements management is a major cause of project failure, second only to changing organization priorities.¹

6S for success!

Stories, Small and Subdivided
Keep it small, break it down. Plan to subdivide into smaller portions and then distribute. It easier to manage and allows for simultaneous effort.  User Stories are essentially user scenarios that users can relate to, based on their own business processes and experience. Keep a single pool of stories (product backlog) for better control.

Divide any way that works: by user interface tier, system tier, business functionality.

Expect the unexpected, unpredictability and ambiguity. Respond to change. Make the switch. Focus on the short-term tangible, feasible priority outcomes and maintain the Product Backlog and include the remaining project user stories with from a high-level perspective (must-haves, nice-to-haves, don’t wants) Plan. Prioritize.

Specific (timed)
Keep the iterations to a maximum 2-3 weeks to keep the momentum, motivation and engagement.

Learn to let go of the traditional approach of managing requirements.Having hypothesis and assumptions are acceptable. Not everything needs to be known up front. As you move along, things will get clarified. Keep it simple.

Agile progressive elaboration
Uncover, clarify, remove ambiguity, validate, often. Iteratively reassessing expectations, having stakeholders voice and clarify all interpretations and assumptions, aligning, resulting in ONE interpretation. Expect change as expectations get clarified. Stakeholders will feel more engaged, motivated, satisfied with short-term tangible results.

Agile Project Management is no suitable for all projects. Project size, complexity, criticality, culture (including active sponsors and stakeholders, capable of handling change) and experience are to be considered. If required, adapt by balancing between Agile and traditional.

What’s your success story?

¹Source: PMI 2013 Pulse of the Profession®. http://www.pmi.org/Knowledge-Center/Requirements-Management.aspx