Change in project management is inevitable, I get it. Things are going to happen, people forget stuff, new technologies come along, and even risks can cause us to change our plans from time to time.
But that doesn’t mean I have to like change.
When I manage a project I’m pretty adamant about first identifying everything that the project is to create. Yeah, I’m funny that way – I want to know what the hell I’m responsible for before I go about trying to create it. Maybe you’re different.
Requirements must be known, identified, and agreed upon before a project manager can realistically create accurate estimates, create a WBS, and actually put efforts into creating whatever the heck the project calls for. Don’t people get this? What’s so tough about saying what you want? This is business, not an afternoon snack at the ice cream shop.
You want to know what the real problem is? People don’t know what they want. They do the old trick of saying, “I don’t know what I want, but that’s not it.” Love it. So project managers need to help people know what they want – that’s what stakeholders need. Stakeholders are looking to us, the project manager and the project team, to tell them what their project needs. They don’t want to looks like fools so they don’t ask. Like a scared guy at the doctor, they want someone to find the problem without actually having to say what the problem is.
So add consulting to the list of things to do for a project manager – and that shouldn’t really come as a surprise. Sure, it’s not a process in the PMBOK, but who cares. This is about getting the project done, not passing an exam. The project manager should serve as a consultant to help the stakeholders, the project customers. You can’t be grumpy or mean or upset when it comes to project customers, and no, I am not just saying that because customers pay the bill. Stakeholders don’t know project management. Stakeholders know sales, manufacturing, customer service, or some other function and they expect the project manager to know project management, which apparently, to them, includes mind reading.
Once all of the requirements have been identified, collected, and documented then the project scope must be protected from change. If all of the requirements have been collected, and I’m assuming they have, then there’s not a real reason to change the project scope for errors and omissions. Once again, I know this isn’t true, but it sure looks nice on paper. My point being, if you’ve collected all the requirements there shouldn’t be more requirements. Requirements from this point forward are scope changes and must be documented, reviewed, analyzed, considered for the entire project and someone’s got to pay for the thing. This isn’t a hobby.
Scope creep is another type of change that gets me fired up. Scope creep is evident in those tiny, innocent changes that the project team sneaks into the project work either as a favor to stakeholders or through moments of genius. Scope creep are undocumented changes to the project scope and they can cause huge problems downstream in the project: risks, cost overruns, schedule issues, scope verification headaches, configuration management troubles, and on and on. Scope creep steals monies and time from the project scope and gives it to junk that’s not in the project. Yeah, junk. I’d say something worse but my mom reads this column. I say junk because scope creep additions are non-value added changes to the project.
Don’t whine and tell me how those changes are good. If scope additions were good, the changes would have:
- A) Been in the requirements to begin with
- B) Been part of the WBS and activities list
- C) Been documented and submitted as a change request
- D) All of the above
Scope creep is called project poison for a reason. Keep allowing the project team to sneak changes into the project and you’ll end up with something entirely different than what was called for in the requirements. And that’s fun when you’re reviewing requirements in your requirements tracing matrix and you can’t match stuff on paper to reality. And then your head explodes. Project managers, project team members, management, project customers, and all other stakeholders must understand the change control processes, the procedures to entertain a change request, and understand that just because a change request is submitted doesn’t mean it’ll be implemented.
