Four Critical Components in Successful Project Implementations

As most project managers know, having solely a project plan does not guarantee project success. We can fill entire buildings with project plans that are associated with failed projects.

I have found in my experience that there are generally Four Critical Components that a project manager must consider when implementing programs or projects to assess the probability of success for his project.

1. Senior Management Support - this is a key ingredient to success. The project must have full senior management support and this does not mean just financially, but that helps of course, but senior management must believe in the output and must advocate for it to the general business community. This is where excellent stakeholder management skills come into play. A project manager must understand what BUSINESS KPIs are important to senior management, how the project supports those and what is the ONE PROJECT KPI that senior management will protect in times of crisis - cost, schedule, quality, scope?

2. A Solid Strategy - Thee project must tie up to an overall business strategy that can span multiple years and it must be an important part of that strategy. The strategy must be concrete (not just a vague vision), comprehensive, sustainable and drives significant incremental value to the company or client. If the project feels more like an off activity then it probably is a rogue project and we all know that at crunch time - nice to have projects are no match to critical to do projects.

3. An Enabled Talent Pool - we all know this - even the best project plans out there will not bring any benefit to the company and the project if the people leading and executing the plans are not properly enabled and/or not the caliber required by the project. Don't be deceived by some people saying that project managers are generalists - the best project managers I have seen are actually specialists. Not to say that they can't run general projects but they excel in their chosen fields. The project team members must also complement one another, know their roles and must be properly resourced to execute their jobs. The most mature team are those that understand that individual superheroes do more damage than good to a team and at the end of the day - it is the entire project team - working as one - that can deliver successful projects.

4. A Consistent and Appropriate Set of Tools and Processes - from process definition, handovers and even documentation requirements - all of these must be consistent and appropriate for the project being undertaken. A good PM will know the different process and tools (like those from the PMBOK) - a great PM will know which processes and tools will be most effective in the project. Discuss early on in the project what processes will the team follow, who will do what at every task (RACI), what documents will be required at what phase and what tools will be used to create and share project assets across team members. Regularly assess as well how the tools and processes are helping the project and be open to changing them if need be.

Finding the Balance between the High Level and the Devil

It is amazing that a lot of projects get derailed because new details are found late in the project and some of these projects even become un-recoverable but sponsors still avoid discussing details during the initial phases of the project.

Understandably, at the early stages of the project, not much is known about the deliverables but sponsors and project managers must consciously allocate time early on to talk about potential risks and not put those discussions on the parking lot with the hope that eventually people lower than the managers will think about it.

Sponsors and Project Managers always say that "the devil is in the details" but let the devil remain uncontrolled. Control the devil - or at least identify the worst case scenarios - early on and the probability of project success increases.

The key is finding balance between defining deliverables and identifying critical risks that might derail the project.

Projects Must Align with Corporate Priorities

In the everyday hustle and bustle of user communications and the desire to serve by managing the low hanging fruits as fast as possible, project management teams are most likely to miss out on a critical aspect of a project - is it really needed by the corporation?

Most of the projects I have seen are more responses to the short term pains of a few groups of people rather than an answer to an over-arching need of the company. Most of these pains are mere symptoms of the root problem rather than the problem itself and thus there are several project teams that deliver what we call "band-aid" solutions rather than long-term pain relief.

There are some questions that help determine where the project request is truly rooted on and what need does it truly answer and some of them appear below. In several cases, just asking the project sponsor a few of these questions can get people collaborating more across peers or having them re-think their original requests.

1. Priority -> How does this project tie-up to the corporate priorities(sometimes call the CEO agenda, the company mission,etc)?

2. Cost/Benefit - > What will the company gain if we do this project? Don't forget to ask as well what will the company lose if we don't do the project? The more specific the answer - the better. It is, for example, better if the sponsor can tie it to profit growth or profit loss or if the user can tie-it to a specific business process problem that the project will address.

3. Project interactions -> Does this project tie-up with any existing or planned projects that the company is already undertaking?

4. Resources -> To what extent will the company support the resource requirements of the project?

It would be an eye-opener if our executives realize how many projects failed (and costed the company money) because the questions above were not asked(or answered) early on.

The Project Management Circus: Act 2 - The Lion Tamer (Project Sponsor Management)

The lights go out for a few second and there is a booming voice that announces Act 2.

A spotlight shines on the person coming into the cage and inside the cage were several lions.

The person has a whip on one hand a chair on the other and he has treats in his pocket. He has been here before and he knows the lions well - each one of them. He knows not only their names but their personalities as well. He knows what makes them tick. He knows he needs them to succeed. He knows they need him to control the chaos that can happen without him. He waves his hands to his spectators as if in victory even before the show begins.

The booming voice announces him as....The Project Manager.

Each project manager deals with this situation for every new project - facing the project sponsors and working with or through them to ensure project success. What does he need to succeed in this initiative?

1. Sufficient knowledge of who the sponsors are and where they belong in the hierarchy of the organization - the pack order.

2. True knowledge of what is their stake in the project - not just what they publicly say - but what their internal agenda is.

3. Knowledge of their comfort levels, risk tolerances and when thrown into a corner - which would they primarily protect if they can only choose one - scope, cost, schedule or quality?

4. Knowledge of their pain and pleasure points which may include what information does each one want to hear, when and how and what motivational triggers can be pulled if the project manager wants the sponsors to "jump through hoops'.

5. Understanding the defense mechanism of each one. When provoked - will Lion A run away and will Lion B attack? If the project manager knows who will go into the offensive as a defensive - he needs to make sure he knows how best to defend himself.

Balancing between sponsor motivation (the treats), punishment(the whip) and defense(the chair) is a key skill that each project manager should develop. It is so much better to know how to manage them that to find your head trapped between their jaws.

The Project Management Circus: Act 1 - The Tightrope Walker

I have heard several people in my career say that project management is easy - just give someone a project, resources and a goal and all he has to do is create a plan and monitor it to completion.

This is similar to what I hear from my co-spectators when I see a circus.

Truly, Project Management can be like a circus - in more ways than one and the performers are the project managers.

Take the tightrope walker as an example. What does he need to do anyway? He only needs to walk from end to end - how difficult could that be? Let see...

A tightrope walker, like a project manager, to succeed in his endeavor, would need to

a)know first where is his starting point - including information about how high he is from the ground, is there a net below him, how strong is the post he will stand on before he begis the walk, what is the length of his balancing pole,  how hot the spotlights can be, etc... - much like project initiation

b) know where his end point is and what is the definition of success (eg making it to the other side alive maybe in 5 minutes), what resources does he has to reach the other point (eg does he have a pole to hold on to and use as a balance), how many steps would he most likely need to take and how much can he trust his resources(eg his rope quality, his pole quality or the net quality if he falls). At the same time, he must know the pace he needs to take and how to take the steps - much like planning, contingency allocation and resourcing

c) know how to traverse the rope and keep his balance ensuring that he checks at each step whether he is on the right track or not. He must also know what to do when something goes wrong along the way(eg an ant is biting his armpit - sometimes called management pressure - or when his rope starts to shake because of a sudden wind gust - sometimes called sponsor wind) - much like project monitoring and control

d) know what to do when he gets to the end - if he gets to the end - including putting the pole down first (let go of resources), ensuring both his feet are really on the other end and raising his arms and waving to his adoring crowd - much like project closure and team celebrations.

Easy you say? Maybe...up until you are truly the one walking the rope.

The Beauty of the RACI

The RACI chart is a standard document in most projects and I would say that it should be a standard in ALL projects ..but what is a RACI chart anyway?

RACI is an acronym and different organizations have different takes on what each letter means and that is why as a project manager, you should be aware of the standards of your client's company with regards to a RACI chart - take the time to ensure you have the right definitions because it can cause confusion later on. It is usually created when a project has just been conceptualized.

Typically RACI stands for Responsible, Accountable, Consulted, Informed. In other organizations, it can mean Responsible, Approver, Consulted, Informed or even Responsible, Approver, Coordinator, Informed. Whatever it can mean, it always answers the need to know who are the people responsible in defining and delivering the project and what is their role in EVERY task in a project. Most RACI chart requires there is only one R for each task or only one A for each task if the A means accountable - a good practive to have.

I recommend having a template of all the possible task that a project can take vs lumping them into generic work that may cause issues later on. The template can then be "customized" based on what a project requires. Remember - a task that says "complete the design document required for all data interfaces" is much more trackable and thus controllable that a task that says "complete design documents".

What is the importance of a RACI when you have a solid, trustworthy team? Each project is unique and in my experience, there is always room for assumptions and one assumption that team members usually make is that if the task is unfamiliar to them - then it might not be theirs and will taken cared of by another team member. Another situation is when the task can be performed by more than one person in a team - you can either have a case of two people doing the same work or noone doing the work.

By having a RACI chart from the start, you ensure that each person knows their role, the extent of their role, what they are expected to do in each task, if any, and how they relate to other people and their roles - a perfect recipe to prevent roles and responsibilities issues later on.

The "3 Whys" and its Power in Scope Control and Management

One of the most successful tools in your PM toolbox should be your "3 Whys".

It is a conscious process of not advocating your thoughts or countering an idea until you have been able to at ask your client aat least 3 Why questions.

An example scenario is when your client would ask you to add something in scope.

A series of Why questions can be the following set and all of them will help you to a)understand your client's motivations in making the request, b)determine the perceived value of the request from the client's perspective and c)give you sufficient knowledge to start a negotiation discussion if need be.

1. Why do you want to add that to the project's scope?
2. Why do you think that by adding it it will add value to the project's outcome?
3. Why do you think that by not doing it we will jeopardize the success of the project?

There are several PMs who rush to a decision or conclusion when a change in scope is requested without fully evaluating the true nature of the request and if it can truly benefit or not a project and its outcome.

By asking at least 3 Why questions (and more if need be), you will not only place yourself in a better position to assess the request but it will also give your client that reassurance that you are interested in more than simply execution.

It is a well known fact that one of the common questions in the PMP exam is the question of what should a PM do when a scope change is being requested. Remember - the most no-no answer is to simply say no.

A good PM should always assess the impact first of the request and the "3 Whys" gives you that good start.