Project Management

Is your project MAD?

Forget deliverable-inspired tasks that produce little useful output. If you want your project management discipline to really shine, apply them to true business objectives.

In the past several years there seems to have been a project management renaissance. While you'll have to pardon me for referring to one of the great intellectual movements and a fairly dry topic like project management in the same sentence, what was once an esoteric discipline is now a topic for discussion everywhere from boardrooms to cocktail parties. Like any good management religion, a cadre of certification and membership organizations has arrived on the scene, bestowing a slew of letters on the last name of anyone that wishes to write a check and take a test, and project management itself has become wrapped in esoteric terminology and incomprehensible mathematic gymnastics.

This increased focus on project management to a large extent has been a good thing. Companies have come to the realization that succeeding at implementing complex projects, like those an IT department frequently tackles, requires more than hope and good luck. Like any discipline, there are right and wrong ways to manage a project, and the project management organizations have done well spreading this dogma. Where they have failed is that many are now placing more emphasis on the mechanics of project management than completing the project the discipline is meant to facilitate.

Many seemingly well-managed projects mysteriously spiral into disaster. Initially everything looks good to the stakeholder committee or CIO overseeing the project when suddenly, usually around the realization phase, everything falls apart. After spending millions to get the project back on track, a "post-mortem" often finds a focus on project management mechanics and deliverables were a distraction that obfuscated the true source of the failure. While consultants and implementation team members produced reams of paper and checked boxes on their to-do lists, fundamental business challenges and decisions remained unsolved or unnoticed.

Taking the tools of project management and applying them to true business objectives rather than deliverable-inspired tasks that produce little useful output is where the project management discipline can shine, and an area where project managers, and those who manage them, need to pay heed. There's no need for additional certifications or tests; look instead at each objective and milestone of a project and ask if it's "MAD":

Measurable - The objective has concrete measures to know when it is completed Actionable - There are concrete steps that can be taken to achieve the objective Dollar-based - There is a positive and financially-quantifiable business benefit to achieving the objective

For example, producing a ream of technical documentation, a classic deliverable, meets the first two tests since you know what documentation to produce and how to produce it. Where this task struggles is that there is little concrete financial benefit that accrues from documentation on its own. One might argue that the documentation feeds a larger objective, say completing a component of a complex system. If that's the case, the completed component should be your focus rather than the documents associated with that component. In addition, focusing on the larger objective brings "soft" tasks into sharper focus. You can mindlessly toil away on documentation when a critical process remains unfinished, or a business decision is stuck in the morass of indecision. When you are evaluating the project by a MAD objective, these gray areas are thrust to the forefront and likely acted upon rather than being buried.

While any value-producing component has a variety of support tasks required to complete it, and one could argue that these task are worth tracking, traditional project management methods focused on these support tasks while missing the larger picture. Countless projects have failed due to a handful of critical decisions that were made too late, or made without proper consideration. Despite mountains of completed deliverables, the distraction of deliverables and mercurial milestones shifted the focus away from realizing business value, and identified these gaping holes too late in the game.

At a higher level, stakeholders and C-level executives can apply this test to determine the health of their projects. If a new logistics system is being implemented, create objectives for the project derived from the business case, for example "10% improvement in transaction time." This objective is clearly Measurable, the project manager presumably has the Actions required to complete the objective, and an obvious Dollar value can be placed on the objective. Have the project test its work against these objectives and the results will provide a clear view of how the project is tracking against its business goals, and create a far more transparent management tool than traditional completion rates. If you have completed 99% of the deliverables, does it really matter if you are showing a 4% increase in transaction times when your goal was a 10% reduction? If you would like more information on using MAD metrics, take a look at this free whitepaper.

With a more rigorous focus on the end-game, project management can save itself from the fate of other management religions gone wrong. Tying objectives to business results also instantly engenders that mythical and elusive beast IT folks often obsess about: alignment. When a project's objectives are concretely and inextricably married to business objectives with a clear financial impact, there is no debating whether IT understands the business, or what all the technical wizardry is actually meant to accomplish. While the conceptual shift is simple, encouraging the mental leap and fully implementing it allows everyone involved in a project, from the CIO to the most junior programmer, to immediately and dramatically see and understand his or her contribution to the business.

Patrick Gray is the founder and president of Prevoyance Group, and author of Breakthrough IT: Supercharging Organizational Value through Technology. Prevoyance Group provides strategic IT consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

8 comments
Tony Hopkinson
Tony Hopkinson

Now concentrating n the mechanics. Hold on, yes your article is dated this year. Now? As far as I can make those who did have a dogma, have been very dogmatic about it. Perhaps there's some correlation. Sheesh we still have people recomending making a project fit a lifecycle instead of the other way round. Can't even get a basic right. As for your comments on documentation, I am rolling around on the floor laughing, that was absolutely hilarious. After all the pseudo science has been done, metrics selected by star sign or possibly phrenology. Then thrown directly into the bin because you wouldn't have got the job, so you cut lumps out of it. What are the first two casualties in terms of deliverables. Quality and documentation. Ok here's the business bit, sit down this might get too complex for you, it involves a strange technical concept. The future.... Version II. II you say, yes comes after I, a progression into the FUTURE Why II, lots of reasons. Things change, things probably changed during version 1. Stuff got sarcrificed, re-prioritised. It turned out to be full of bugs, no bugger knows how V1 worked. Things that happen, come to light after the project was deemed complete, yes it's here again the FUTURE. Ok have you any vague memories of versions IIs or even IIIs. OK that was unfair of me, another new concept, the PAST. So now you are on version II, well you aren't, you got promoted because of the massive 'success' of version I. Version II adds and changes I, (technical bit here. to do that you need to know how version I works, and nearly as important why). So we'll consult the documentation.... You aren't the solution, you are the problem... So clear business impact, it's very simple. Software changes, to change it well and cost effectively, you need to know how it works now.

ottersmoo
ottersmoo

Everything in moderation. In the case of IT projects specifically, documentation cannot be separated from "getting the project done". Otherwise, if you have a sudden problem in employee retention, nobody knows what the previous team did or how to perform maintenance on it. Think about if you have contractors implementing the technology. Documentation is essential and cannot be set aside in the interests of getting the project "done". I agree that things can be bogged down in the methodology. That's where moderation comes in.

mford66215
mford66215

Mr Gray's been doing some good work. The slow cultural shift within the project management industry from task oriented deliverable inspired monstrosities to business enhancement vehicles is finally starting to happen.

jodyharris5016
jodyharris5016

As a Project Manager I am steeped in the PM method. This being said I have a strong IT background and I know that the expedient implementation of an IT project can save money, and make money and in the case of my project at a very prestigious medical facility, it can save lives. My motto on this project is "Paper does not stop Progress". There is no amount of documentation that can replace the output of the project. IF it is worth doing, then do it and write about it if you must but completing the project is the goal not compiling enormous mounds of paper. My project provides all of the MAD criteria but the final value is not money. It is life. Joseph "Jody" Harris Jr. PMP Mayo Clinic

DonSMau
DonSMau

I like the concept of "hard" and "soft" milestones and MADding each one, but there are plenty of key deliverables that don't have a direct $ value but will have a value in terms of reputation, regulatory compliance, or operations -- and a lot of those will be documentation.

nsukky
nsukky

This seems to be just bashing at the discipline of PM. there's definitely more to gain than lose from PM training, dear author, so please, don't diss it. Ever witnessed a project where there was no PM methodology employed, and the "Project Manager" was focussed on "delivering the project, never mind those reams of paper"? I'm living in such a nightmare.

RoseJM1884
RoseJM1884

...and the beatings will continue until the engineers' morale improves...