I find that I’m often inspired by the sermons at my church to write a project management article. It seems like an odd marriage of ideas, I realize, but it somehow works for me. Well, this past Sunday’s message was no different. As our pastor was talking about ‘saying no to say yes’ – meaning basically saying no to certain things so that our hearts and minds can be open to other things God’s will has in store for us – it struck me that this is, indeed, applicable to the project management world. I quickly diverted my attention back to the message (after making a quick note on my iPhone for later reference) and now I’m trying to wrap my mind and words around the concept for this article.
As project managers or project team members we find ourselves often buried in the very detailed and sometimes overwhelming tasks that make up our current project loads. If we did everything for everybody we would truly go crazy. Plus, all those customer requests (“Could we tweak the website to look like this?”, “Could just add one more reporting function for this data?”) would drive our project budget into the ground if we fulfilled each one without question. Extra work that isn’t documented isn’t paid. And unpaid work = a failed budget and often a failed project. Ouch.
We hate to be killjoys for our customer. After all, a happy customer is usually not the customer who gets told ‘no’ too often. But really…we have to do that from time to time. And the buck stops with the project manager who should always be monitoring the project and protecting the project schedule no matter what. Certainly, collaborate with the project team and customer using a nice schedule viewing tool like Seavus’ Project Viewer, which enables everyone to see the schedule and collaborate without needing to buy an expensive MS Project license. But monitor that project scope closely…very closely.
Is your project customer going to be disappointed? Possibly. The key is to look at those extra requests and verify them against the requirements you documented with the customer at the outset of the project. Does the request match up with the requirements? Is it feasible that the request is ‘in scope’? If it is, then by all means proceed. But if it isn’t, do yourself – and your customer - a favor and discuss it in depth and come to the mutual determination as to whether the request is a valid one and is necessary for the project. If it is, then a change order is needed to keep the project budget and timeline on track. The customer should be able to understand and value that. But at least they have a chance to say yes or no to the change order. You’ve jointly decided that it’s out of scope and they’ll need to pay for the work – and likely agree to a slight schedule adjustment to accommodate the work – in order for the new request to become part of a new, modified project scope.