Is #scopeCreep on projects a bad thing? I don’t think it is… #pmp #pmi #projectManagement

I saw an email pop through from the Project Management Institute earlier this week. It said something like “finally stop scope creep!”. People fear scope creep. A lot!

I have to be honest. It did make me chuckle.

I started using Agile about two years ago. I have used waterfall for my project delivery for a long, long time but started to use agile and the associated methodologies after my hand was forced.

I like waterfall. And I have to agree that when you are working on a project to which you have no flexibility, then yes, scope creep is a pain. In the waterfall world you have a schedule, you have key milestones, you have a governance board, you have signed off the requirements 'in blood' ensuring that nothing changes… And then, what happens? There is a change to requirements. Rebase line to the schedule occurs, change control takes place, risks get written due to the impact on budget and time, money doesn't increase (well, hardly ever does) and to top it off, everything else that was 'signed in blood' has to be done as we…

Due to all of the rework people really try to avoid scope creep.

On the grand scheme of things this is not good. This is a bad thing. A very bad thing. Avoiding scope creep is not good, embracing scope creep is good. I'll explain.

Scope creep is, in my mind the customer realising that they need to tweak and / or significantly influence the product to ensure it gives the value they perceive. I have seen a lot of projects go into PROD which stare they have 'delivered' only for the product to be disliked and require significant change post 'delivery'.

In my waterfall experience we write detailed documents articulating a requirements for a product of which the user hasn't ever seen. Nor have they really been able to imagine using (specifically 'using') the product. To ask someone to stick to something that is purely conceptual is not a good idea. Take the amount of feedback we get as project managers when something hits UAT. The volume of bugs, and more often than not, the volume of changes raised, spikes quite considerably. That's because they are using the product and actually assessing if it will provide the value they thought it would.

Secondly. In the world we live, things move fast. Regulations. The markets. Even the technology itself, all moving at such a pace it is hard to keep up. Things change, and so do peoples needs.

Managing scope creep is hard, but avoiding it at all costs is not a route for success. Embrace scope creep, manage it well, and you will have a significantly better product at the end.

 

, , , , , ,