Dealing with scope creep (extra project deliverables sneaking into a project outside the change control process); particularly on software projects can be tricky from my experience.

 I remember this from when I first started out as a Project Manager on a complicated customised implementation.

 Requirements from information about the previous manual system were still being gathered when design and build phases were underway which added risk that we would have to do some re-work. Fortunately the client understood this and the nature of change requests for out of scope work, or so I thought.

 What caught me out was when the developer demonstrated an alternate, graphical solution to what was a text based screen.  The client was happy with new approach and the developer assured that it was easy to finish off and integrate.

So a happy client, better product was on the cards.

Unfortunately it did not work out that way.

The code didn’t quite work as well as expected and the client wanted “minor” changes which meant we were pushed on schedule and budget.  Worse, the integration was a lot trickier than expected.

 In short, what looked like a simple job turned out to be a major job that impacted on the quality of the product and the schedule of the project.

It also set us back on budget as this was a fixed price project.

 I learnt a lot from that experience, including:

• A change is a change no matter how small;
• Correct change control protocol should always be followed;
• If as project manager a change is given away then the same will be expected in later changes;
• Customers need to be educated in regard to the change control process and why it is there so that tension can be avoided when changes arise;
• The project team need to know and understand the rules around changes.

 Also, experiences like those above also show how important lessons learned are to future project success.

I’ll write about lessons learned in another posting.