Not writing Scope down is the biggest regret of Project Managers around the world. The biggest regret. Here are a few other learnings, mainly learned the hard way. And as much as I would not like to admit it, they were learned over several instances⦠several instances of Scope Creep and heartache (the name of my band!)
Training â part one
My first day on the job as a Project Manager, my Sponsor invited me to a meeting between himself and the other senior managers/stakeholders of the project. My Sponsor had $12m for a new systems upgrade. He wanted to use it for the new systems upgrade. The other senior managers in the room, however, wanted the system upgrade and all their staff trained.
The main argument revolved around who was paying for training. The Sponsor wanted to build the best systems solution that the organisation had ever seen. One that would finally take care of the many fundamental root causes with our existing antiquated systems. The business units, who already had their annual budgets allocated, were more concerned that there wasnât enough left over for training all the staff (and it was going to be all the staff!) on the new system.
Arguments ensued. There was yelling. There was screaming. There was me, second-guessing my recent career choices. Finally, after all the commotion calmed, there was compromise. The project budget would pay for half of the training; the business units would pay for the other half. That was my introduction to project management and to Scope!
Lesson: Agree Scope with Stakeholders upfront and there will be negotiations.
Training â part two
Another project agreed to create the deliverables âTraining Materialsâ. The stakeholders understood this as âtraining materials and deliveryâ! As training is usually done towards the end of a project (if itâs included in the project Scope, at all), this misconception was not uncovered until the end of the project, when most of the project budget was spent. Again the problem for the business units was funding. As their annual budgets had already been earmarked for other things, the arguments, negotiations and compromises that ensued were âbloodyâ and long lasting!
Lesson: Define and agree Scope in terms of Deliverables and Activities (seems redundant, but trust me, it is not!)
Marketing
Two related projects were being done at the same time. One to create the new product, the other to distribute it. Neither project mentioned Marketing in their Scope statements, as they had focused on included items in Scope and neither were planning on doing marketing activities on their projects. At the end there was a product ready to be sold, delivered to the correct sales points and no one knew about it.
Lesson: Scope means inclusions and exclusions.
Ongoing support
The client had just assumed weâd stick around for an undefined period of time until they were comfortable maintaining the new systems we had installed. Where this assumption came from, Iâm not positive. I think a previous supplier had done this for them (most probably as part of their contract), but this was definitely not part of our remit. We had already scheduled all of our technical resources to be assigned to other projects right after this one.
Lessons: Scope means inclusions and exclusions (again, so important!). Document assumptions.
Ongoing maintenance
I got a phone call from a client about 6 months after their project went live. They had a problem with their system and wanted us to come fix it⦠for free. We did have an ongoing maintenance clause in our contract with them, but for 3 months. The senior manager at the client site had signed our project off after the 3 months, but the users at the client site didnât know that.
Lesson: Communicating about Scope is done at the beginning, middle and end â throughout the project, with all the stakeholders.
Other departments/business functions
We were hired by the Sale Department of a large organisation to install a new hardware and software solution. We agreed and documented Scope very thoroughly. During the project, other (quite powerful) stakeholders within the large organisation kept attempting to have us tack on a bit here or there for their Departments, âsince we were already doing that activity alreadyâ. It was intimidating at times. Especially when the technicians were approached directly by some very senior managers to âjust doâ them a small or simple favour⦠it was never small, nor simple!
Lessons: The project team are stakeholders. They need to really know Scope. And they need to be empowered by Scope. There needs to be processes for dealing with Scope changes and the project management team structure to back them up.
What Scope lessons have you encountered, once or many times?
Leave a Reply