Do The Right Things Right
| Posted in Project Management | Posted on 17-02-2010
7
What do you do if you get asked to handle a wrong project that if it was your call you wouldn’t do it at all? I have seen many discussions about this topic on Twitter, while the main duty of the project manager is to deliver the project within the triple constraints, yet effective project managers focus on delivering value rather than a dummy deliverable!
The famous quote of Peter Drucker tells us that management is doing things right and leadership is doing the right things, if you try to relate this to projects, a project would be a “thing”, a project sponsor would be the leader and the project manager is the manager. We all know that some projects are useless and do not deliver any value, while the project sponsor is the first responsible for selecting this kind of projects, the project manager has an important role to play in this matter, imagine yourself managing a project that you know will not add any value, so you decide to proceed with the project and work on deliverables, if you opt to use this approach you should not be amazed if you find the team demotivated and in fact if you care about the quality of projects you should be managing you will be the first demotivated person! You also may be blamed for a useless project even when you deliver on time within budget and to scope.
Success is not measured by delivering a project within triple constraints or not even with compliance to requirements, success is measured by delivering a value, think of a project to deliver a book that eventually doesn’t get sold because the subject is not interesting, while it may not be your responsibility, as a project manager, to select the right project, but you always have to give recommendations and communicate your concerns, provided that you are the most one who has clear perspective of the project, even if your recommendations get rejected, your situation will be much stronger when everyone tries to put the blame on you when things go wrong
Although we all know the value of lessons learned activity but sadly it is one of the most abandoned activities in project management and in business world in general, there is one interesting exercise that you can do, try to look at projects/activities you and plot them on the above four quadrants grid, ideally you should ask team members and stakeholders about what went wrong and what went right, it would even be better if you can map the WBS (Work Breakdown Structure) to the above grid, after doing this exercise you will have projects/activities under one of the following:
- Right Things Done Right:right things are result of having a vision, and getting a mission that is based on the vision and core values, a mission would be comprised of projects that are properly planned and implemented
- Right Things Done Wrong: while the value can be delivered via the project, the project may fail due to any reason, the common denominator of these reasons is associated with planning, you can read my series Why Projects Fail for more about projects failure
- Wrong Things Done Right:that’s related to doing projects that lack the vision and do not fit in the company’s portfolio, or can be related to certain module of the WBS that should not be part of the scope
- Wrong Things Done Wrong: the project is based on no vision, does not deliver value, and is not well planned, while the bright side may be that the project should not have been done in the first place, but doing it in a wrong way exhibits awful failure and maximizes the loss
How to handle valueless projects
[quote]If you get a valueless project that is very likely to fail, you have to communicate your concerns clearly and provide advises and recommendations to the sponsor and stakeholders if your recommendations get rejected you can just document these options and proceed with the project or simply quit the project if you have this sort of luxury, at the end of the day everyone seeks success and nobody wants to be part of a failure!
And now how about you? what do you do if you find yourself managing a doomed project that you know will not deliver a value to stakeholders, Do you say it loudly? or do you just keep silent and work on it? I’d love to know about your experience, Thanks.
Loading ...
on 
Mohamed (25)
Ahmed A. Korany (14)
Venkatanarasimha KL (9)
Pawel Brodzinski (8)
Shim Marom (6)
You addressed a nice solution for the subject, but, for most of the projects that I have dealt with recently, I used a similar strategy which is: “Raise the Flag [Document it] and continue”, I don’t want to get deep in what I have seen, but, sometimes, stakeholders do pick up wrong projects which’s rarely happen to turn into right ones
Anyway, Nice post my friend, I liked it.
MAG
Many PMs follow “Raise a Red Flag” strategy to avoid being blamed when things go wrong, while this strategy doesn’t always save the day and makes the environment tense, it works in unprofessional environments
The sad thing is that a project manager’s work will not be appreciated if the project was finally found to be a WR project. He will think twice before listing this project in his CV. Using your analogy, a publisher of an unsold/unread book will simply try to avoid bragging about it.
For value less projects We start Negotiating the requirements with the stockholders and see why they think it’s valuable for them , and later stage try to re-engineer the process to work on the way I think that it gives them better results and If they refused my modifications I work on the project after documenting what happened and doing that task as it’s.
In order to understand the value the stakeholders believe is inherent in the project, I start with understanding the business objectives. What business problem is being solved or what new capability is brought to the business. Once the project manager understands these objectives, then the project is structured around achieving these objectives. Requirements, deliverables, code, etc is all focused to achieve the reasons why the project was initiated. Information Technology IMHO is just a tool and that tool is to move the business forward.
As Kareem stated, the project manager must deliver value and this is what the success of the project is ultimately judged upon and not the triple constraints.
Mark,
I think this is the correct and logical approach to be taken for successful projects, the problem is that not everyone honours the business objectives while the project is progressing, another issue is that people may know what the problem is and they may also be totally aware of the business objectives, however solution has a big share in doing things right, in other words a business problem can have many solutions, and selecting the right one, that’s not necessarily the best one, is what can make the project successful.
I agree. In my experience, understanding and remaining focused on those objectives and achieving those objectives is a stronger criteria for success than the triple constraint. I believe that the role of the PM is to maintain the connection to the objectives and ensure the solution does meet these objectives. At times, producing a deliverable that maps the solution components to the objectives has proven valuable in two ways: 1) ensuring focus and understanding by the business team, 2) assisting the technical team to understand the context of each solution component and how each component fits into the overall project success. This understanding also assists in motivating the technical team but that is another topic.
The individuals that typically digress from those objectives are not the business owners. In order to ensure success, the PM should remain focused and keep the team focused on why the project was started. I use status meetings, steering committee meetings, and customer meetings to always relate back to those objectives.
The definition of success for projects is changing I believe from the old triple constraint to business value and IMHO the business objectives is the PMs way to ensure this value.