Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Category Archives: Stakeholder

How do I handle external pressure?


Project management principles are the same world over. However, the application of those principles vary widely depending on the type of organisation you are in and the type of external pressures you face. Here I use the word external to mean influences outside the project, rather than the organisation. PMBOK and PRINCE2 contend that the Project Manager runs the project on behalf of the governance team or the project board, so the decision on project selection and business case rests with them. Most organisations will use the experience of a Project Manager to determine the business case.

I work for a niche technology company that predominantly provides professional services and software development. Recently we have moved into the product sale market. One constant pressure we face is to limit costs of professional services in order to land a product sale. This is not unique to our company. There is always a judgement call between the appetite for cost the customer has in determining the final price. Regardless of the pressure, the effort required to deliver the outcome the customer is after does not change.

When there is internal pressure to reduce estimates, the Project Manager can negotiate with the sales staff to reduce scope as a trade off. That does not always work, as professional services companies are rarely in the position of setting the agenda. More often than not, they are responding to a demand based on gaps in the customers core staff. Usually everything is a must have. The question at this point becomes not a project management one, but a strategic one for the company. The project may be desirable despite possible overruns in the current project. There may be future projects, or may provide foot in the door to a particular segment of the market or may be a key reference customer. It is the Project Manager’s responsibility to quantify the cost appropriately, so the management can make an informed choice about how much risk they wish to carry. Simply adhering to the wishes of the sales staff is a dangerous game to play.

A second external pressure that constantly challenges project estimates is the pricing of competitors. This is a more difficult proposition to deal with, as the parties are outside the organisation and you will never have the full facts to compare your estimates. The opposition may be desperate and willing to undercut any estimate you provide. Equally, they could be significantly underestimating the risks and deliverables. The key here is to not look at your competitors on a project basis. Look at the pattern over a period of time and see if they are making a success of those projects where you are being undercut. If they are, then challenge your teams to sharpen their estimates. Be mindful though, there will always be cowboys in the market and clients willing to make to do on shoe strings. If that is the case, move on. Choosing to compete at that end of the market will be at the cost of reputation and professional satisfaction.

A third challenge a project manager faces is trying to recommend when a project should be terminated. Usually business cases are made to start a project. It is less common to continually validate the benefits sought in the business case as the project is in flight. Things can get complicated if it is a pet project of someone higher up in the organisation. It is imperative that a Project Manager is aware of what benefits are expected out of the project. That will allow for quantifying accurately if the benefits sought can be achieved based on realities of the project. Nothing is black and white in projects. That is why they are temporary and higher risk than Business As Usual activities. In some cases the organisation may decide risk to reputation is worse than loss in a project.

Projects are inherently risky and pressures are a fact of life. How we deal with the risk and how we quantify it to management is where a good Project Manager stands out. It is the organisation that makes the decision, but it is the Project Manager that provides the analysis to facilitate that decision.

How do I lead when I’m not the line manager?


If you have been managing projects for any length of time, you will have come across scenarios where you are utilizing resources in your projects that actually do not report to you. This is true regardless if you are coming in from the outside and managing a project for an organization, or you are part of the internal Project Management Office (PMO). The project will be identifying resources that may be a combination of existing subject matter expertise and some external skills to complement specific gaps. I have found Project Managers from an internal PMO finds it easiest to deal with external resources for the project. Internal resources usually have their own line managers to keep happy. They are the hardest ones to manage. External resources can be difficult, as they are beholden to the organization, not the Project Manager.

Cross-functional teams are all too common to make worrying about it any use. In fact, this is how project teams should be structured. Most change initiatives will require expertise across the organization, rather than simply a collection of software engineers for example. A Project Manager is not the correct person to lead a team of that nature in day to day business operations. What then does a Project Manager to do to ensure a successful project?

Most successful projects have one thing in common – a sense of purpose for the required change from the top management of the organization. From a project point of view there are two options open to the Project Manager – the carrot and the stick. First is an inclusive approach – to get the line managers contributing resources for the project to be stakeholders in the project itself. If that is not viable or the managers simply refuse to engage, then ensure the mandate for the project comes from above the line managers. They will then have reason to direct their subordinates to contribute towards the success of the project. If the Project Manager is left holding neither carrot or the stick, then consideration must be given whether they should continue with the project. Ingredients are perfect for failure.

If the first hurdle has been crossed and there is buy in from management for the project, it still not a guaranteed success. Actions always speak louder than words. It is easy in theory to provide some resources to a project. However, when push comes to shove, line managers always have the ability to pull the rug from under the project. Consider some practical steps to make that less likely. One approach could be to have the project team located together, where day to day influences can be reduced by the project team around them. If someone has been allocated to the project for a set period of time, they can be provided new contact numbers, email addresses etc. If they have been assigned on a part time basis, it is incumbent on the Project Manager to know the likely demands on that resource. If the resource is involved in billing, beginning of the month may be particularly busy for them and project work may have to be planned outside the first week of the month.

A cross-functional it is precisely that. In their day jobs, they usually do not deal with each other. For many of the team the thought of accountants sitting next to software developers or scientists may be a bridge too far. Project teams by nature have to be less change averse than the others in the organization. They are the ones that will produce the products that will achieve the change. The Project Manager should seek out team members with those qualities.

Above all, a Project Manager needs to exude authority, understand the purpose and be able to communicate that effectively to the team. If that can be achieved, the team will follow.

How do I manage a distributed team?


As the world becomes smaller due to more efficient communication, distributed teams are becoming quite common. If you ring a customer service line in any country, the odds are you will end up being serviced by someone in Manila. Your latest Microsoft software was most likely developed in Bangalore. I have been managing projects with teams and clients  scattered in different parts of the country, and in some cases spanning multiple continents. I have been thinking about some of the challenges I face and how best to overcome them.

The biggest and most obvious challenge faced in managing distributed teams is the fact that you are not where they are. Even with all the new technologies, talking face to face remains the best form f communication. There are many forms of communications in projects – the truths, the half truths and the outright guesses. When you are managing the deliverables, you need to be on top of what is what. While this is not an insurmountable obstacle, it is a rather expensive one to mitigate. People work best with people they have known personally. They are more likely to be upfront with realities, than someone they find hard to relate with.

Working in different time zones also amplifies the problem. As an example, I work out of New Zealand and work with people in the west coast of the United States. During the southern hemisphere summer, it is reasonably workable, with abou 5 hours overlap. However, we lose a day. So we get about 20 hours during the week. In winter, during the Pacific Daylight Time, the overlap is as little as 12 hours. Our other base is in India, which starts work as we are leaving for the day.

Work cultures vary in different parts of the world. That plays a significant part in bringing a team together. New Zealand has a very relaxed working environment and an excellent work life balance. This is not to say, Kiwis are lazy by any nature. A lot of our innovation comes from this part of the world. I find Americans are much more intense with their work and put in significantly longer hours. Consequently there is always possibility of conflict if the teams perceive each other to be too pushy or too relaxed. Work cultures also vary in how people communicate bad news (or how they do not). While you do not want bad news in projects, if it does  pay to get it early.

If you are indeed managing people from all the different locations, the likelihood is you are not their direct line manager. They are each likely to have their own line managers to keep happy. This in itself is not uncommon in a project scenario. Temporary assignments from operational teams is a routine occurrence. It is quite different when you are not there to ensure the story you get is the reality, rather than the party line.

You can alter your usual working hours to accommodate additional collaboration between the teams. You can utilize advanced telecommunications to give a feeling of co-location and one team culture. These are all good measures, but intermediate ones. The more the teams are isolated, your picture will be less realistic and you will struggle to enforce uniform processes across the teams. The only way to bridge that gap is to ensure regular face time.

If it s important enough to have distributed teams, it is important enough to ensure effective management.

How do I communicate project schedule?


I asked some of my colleagues about their impression of the project management discipline. One comment that was near universal was the impression that Project Managers are unnecessarily wedded to their Gantt charts. Having given it some thought, I tend to agree. Project management is a discipline that is used to deliver business outcomes in a predictable nature. Project management in itself is not the deliverable. Therefore, visibility in the project team shouldn’t be the various project management artefacts.

That got me thinking … what do we use Gantt charts for? It helps us establish order of tasks, assignments, critical path, identify slack etc. Well and good. Now the project manager has a good understanding of the tolerances afforded to him within the project, in terms of time. Now what? The Project Manager is interested in the entire picture. Not all the teams involved in delivering the output of the project is interested in the whole picture. they want to know their schedule and an overall picture of the project. How do we give such an overview picture without too much extra work?

TimelineThe key here is to understand your stakeholders and what each one needs or is interested in from the Project Manager. Most stakeholders need to understand the overall timeline and workstreams for their teams and those around them. I have found the Timeline feature in MS Project 2010 to be particularly helpful for this. You can create a timeline with the required level of detail straight from your Gantt chart. This is a more simplified view of the project and may be quite a good tool for many of your stakeholders.

High level project sponsors are unlikely to be interested in the actual timelines. Their concern probably begins and ends with your expected delivery dates and cost profile. Gantt chart is a total turn off at that level. Think about using something like Earned Value Analysis technique to show your progress and likely final cost and completion date. That is likely to get a more to the point feedback, than Gantt chart. Think about an IT project that is geared towards achieving some business efficiencies in a billing system. Your CEO is less likely to want to know about building of virtual servers than if the final date and cost is still under control.

This is not to say that the Gantt chart is not the tool to communicate schedule related matters with anyone. You need to use this to communicate the individual tasks for various teams and to give an understanding of dependencies. Just becasue you need to use the Gantt chart, do not be shy about using only parts of it relevant to the different teams to get your message across.

I will be paying more attention to what each of my teams are after to adjust my communication style in future.

Under promise over deliver?


Under promise

I was part of an interview panel recently to employ a new Project Manager. Interview was iterating towards a good outcome and we started discussing the philosophy of project delivery. The specific phrase that came up was the often used under promise, over deliver and it’s appropriateness. It was a very interesting discussion, one that I thought I’d share.

The classic reason Project Managers try to under promise and over deliver is to mitigate risk. Once bitten, twice shy. This approach has come from project managers who have been burned by failing to control expectations with their stakeholders. The reason for this failure may have been varied – from unrealistic targets or unreasonable stakeholders. Whatever the case, minimizing impact on the project is the prime concern for them and has led to this approach finding a strong foothold. Perception is reality in IT service delivery. If the stakeholder’s expectations are being met, usually they’ll consider the project value for money.

While this provides for a level of Cover from risk, it goes against open and transparent communication. All the interaction is between competent professionals. This level of communication gap should not be desirable. In saying that the Project Managers currently intentionally setting lower expectations have at one point tried that. Is that an indication that open communication is an aspiration that can never be reached?

I find this all depends on the maturity of all the stakeholders. How you communicate to them usually mirrors how you communicate with your family. There are those family members who are mature enough and you can call a spade a spade. With them, you can aspire to have a transparent communication channel. Set the expectations and if something is to go south, explain the reasons and how the course will be altered to meet the best outcome. There are always some in the family who really care, but don’t get it. In stakeholder terms it is really important to keep on-side, but you probably want to ensure a need to know information flow only. Then there are the in-laws, who you never seem to be able to win over come what may. This is the audience where under promise and over deliver is an entirely valid strategy.

Aspire to openness as the first choice. But be prepared to alter strategy depending on the interest, influence and nature of the stakeholder.

%d bloggers like this: