"Better" is the Enemy
Differentiating Between the Needs and the Wants on a Project
If you're doing your job as a responsible project manager, you will often need to say "no" to your team. And it won’t always be easy…
On a past telescope project I worked on, one of our scientists approached an engineering manager within the project and convinced him that we needed to buy an extra optical-grade mirror to support the operational needs of the observatory. The two came to me and made a very impassioned and heartfelt argument for this optic. They pointed out that we already had a large contract with a vendor to produce a series of mirrors and beam-splitting optics for the telescope. This new mirror that they were proposing would be a relatively low-dollar addition to that contract (less than 4% total change to the vendor’s contract price, or less than 0.009% of the entire telescope project cost.) The optic would add increased functionality to the observatory, and it would greatly improve operations once we handed over the observatory to the scientific user community. It would increase efficiency and, ultimately, improve scientific output of the observatory. For a relatively small dollar change request, we could get a large performance return on investment.
I listened to their arguments, asked a few pointed questions, and then, politely, said, "no."
As we were entering the last full year of construction, money was beginning to tighten up on project, so this was an obvious first consideration.
Further, schedule and personnel priorities were also important; putting this change in place would require valuable FTE-time to spec, bid, contract, track, test, accept, deliver, receive, and, ultimately, install this mirror on the telescope. Our team was already fully booked and completely scheduled throughout the entire remaining year. I really don’t have the spare personnel to manage this additional work.
But the most important reason I said no? This new optic was a want, not a need.
The proposed additional mirror was not in our then-current (and configuration-controlled) work breakdown structure. It was not part of our required scope. It was not something the customer had even asked for. Adding it would be scope creep. Classic scope creep. It was change for the sake of “better.”
And if you haven’t heard me say this before, I will now: Better is the enemy of good enough on a project. Better, more, and perfect are some of the million little cuts that lead to the death of many a project. Scope creep, even small, seemingly innocuous and trivial scope creep, can and will derail your project. You must be on constant vigilance for this insidious problem.
Your job as project manager is often to say no to your team. Engineers and scientists (and sometimes even upper management) will often want to do more, to do better, to over-deliver...
...ah, but this is anathema to good project management practices. Your job is to deliver the product scope—no more, and no less than agreed upon—on time, within budget, and meeting the quality requirements. Period. You are actually failing as a project manager if deliver something beyond the promised product scope.
In the end, I told the scientist and engineer that if they still felt very strongly about this, they were welcome to write and submit a formal change request to the change control board, or CCB. And we would absolutely consider it at the next scheduled board meeting. But unless there was a more compelling reason presented other than just making the observatory “better,” the CCB was likely going to reject their request.
Why? Because in the world of project management, better is absolutely the enemy of good enough.
Have a question or comment to make? Please leave your feedback in the comment box, below.
(Also, remember that you can always contact me directly with a question via email by clicking here.)
And finally, please, please, please don’t forget to sign-up for our email newsletter list to receive a free PDF copy of: