The Lost Art of Project Management

August 17, 2011 | Author: PM Hut | Filed under: Project Management Musings

The Lost Art of Project Management
By David Blumhorst

As both an IT-PMO Director and CIO, I’ve had occasion to hire and evaluate quite a number of project managers. During one of those stints a colleague of mine and I decided project managers generally fell into two camps - what we called task managers and project leaders.

The task managers had the “science” of project management down pat. They could put together great task plans, log issues and risks, and produce project status reports. They loved checking off tasks as complete, checking off requirements as done and completing projects on time, on budget, and on scope.

Problem was, they often missed the target. Say we started a project to enable customers to configure their product on the Web. We had one of these that was proceeding apace using the then-current technology. The PM dutifully checked off the tasks, kept the project in scope, and we were well on our way to having working screens and data. But as I looked at the result, it seemed to me to be difficult to use and required a lot of maintenance. One of the Web developers on my staff suggested a new technology that she claimed could be used to get a better result in half the development time - and she was right. I killed the project and we started a new one. I put the developer in charge of the new project (not a formal PM by training), and we ended up with a great interface that was easy to use and easy to maintain and modify.

What was the difference? The technical project manager did not understand the business target. Indeed, he was not trained in Web development and did not know the technologies. But he did know how to “manage” a project. The problem here is a project isn’t something to be managed - it as a process that is intended to achieve certain business outcomes. Without achieving those outcomes, the money and time are both wasted.

Project Leaders, on the other hand, have a good sense for business and understand the desired outcome. They then lead and motivate a team to accomplish that outcome. In one of my favorite projects - an ERP implementation - the project manager knew that managing users expectations as we migrated from one major system to another would be a big challenge. She worked with me on the internal political problems that inevitably arose, and made an ally of the biggest internal skeptic. I knew we were ready to go live when I talked to the skeptic and she said “I didn’t think we could do this, but you know what? We’re ready”. If the skeptic says you’re ready, you probably are, and we successfully went live that weekend. This project manager was also not shy about changing scope and requirements if needed to make sure the processes we were implementing turned out right in the new tool, and asked for a slight extension and budget increase. We were slightly over budget and time, with numerous scope changes but guess what - we had a successful ERP implementation in a global company. Not a small achievement by any means.

So what do I look for in project managers? People who understand that project management is as much art as science. People who have the soft skills to understand the business outcomes and lead a team to deliver those outcomes. They need to know the fundamentals of project management, but even more so they understand project management is a craft - and they are masters of that craft.

David Blumhorst is the VP of Professional Services at Daptiv.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

4 people have left comments

I think the key to this is understanding the objective of the project as it is given to the project manager. Was the PM in your example given the objective to deliver the chosen solution or deliver the business benefits?

You may say it is always the responsibility of the PM to deliver the business benefits but this won’t always work in practice. In your example, if your PM had not been involved in designing the original solution, he may have had no control over whether it was the best one. He just met his responsibility to deliver it.

I managed a project to reduce the cost of deploying PCs in a large organisation. I was responsible for introducing a new deployment method that was fully expected result in lower costs. However, there were many variables outside my control which meant no one knew whether the cost savings would be achieved. There was no other better solution but I could not guarantee that the specific cost savings would be achieved. i.e. They weren’t dependent on the successful delivery of the project, they were dependent on the accuracy of earlier assumptions and other things outside my control as PM.

There will always be a trade-off between the success of delivering the business benefits and the ability to keep the project to time and budget. The sponsor needs to decide which is more important.

In your example, you threw away an almost finished project and started again. You had the huge advantage that the new approach was half the cost of the original one, so not much was lost. Suppose the new approach had cost twice as much. Would you still have followed it?

Julian wrote on August 17, 2011 - 6:51 am | Visit Link

Excellent article, David. I wish more people would be aware of this important difference. Scrum would give this responsibility mostly to the Product Owner - but in fact leadership means a lot more. It’s not only about knowing (or finding out) what a successful product would look like, it’s about stepping in and taking action whenever the team gets stuck or can’t perform perfectly well. A leader helps to clarify priorities, valuate new input, organize more input if required, improve team processes, judge alternatives, challenge decisions and much more. A mere administrator doesn’t do all that, and it’s left to chance if others fill this gap or not.

Steffen Lentz wrote on August 17, 2011 - 2:33 pm | Visit Link

A traditional PM (as in your example) works with subject matter experts (SME)and architects (in IT projects). It is the responsibility of architects to provide the usable solution. PM is responsible for delivery as per the scope and requirements and not for the technical feasibility of solution.

Also, there is always QA team who is responsible to find gaps and usability issues. A PM delivers a solution only when it is approved by the QA team.

What you mentioned is applicable to the small project where PM plays multiple roles - team lead, architect and of course PM.

Yanesh Tyagi wrote on August 18, 2011 - 6:31 am | Visit Link

You seem to have polarized the market with this article. I’m with you. Without a solid business objectives focus and sound people/political skills modern PM theory will only lead to failure. The art comes in knowing when to use the soft skills and when to use the methodologies.
The soft skills only come with practice, they can’t be taught out of a book.

Len Ashby wrote on August 18, 2011 - 7:55 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories