Project Management in Practice

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

Tag Archives: Project manager

Working with Project Sponsors

I went to the Wellington PRINCE2 User Group meeting this week. The topic of the meeting was working with project sponsors. The user group has a format where it invites three speakers, each speaking for seven minutes and no PowerPoint is allowed. At the end of the talks, there is the opportunity for Q&A, group discussions and networking. The three speakers were all of exceptional quality – Philippa Jones, Don Robertson and Dr Judith Johnston.

It was an interesting discussion led by three very experienced project sponsors, some of who also had experience in project management. The key point that came out consistently during the night is that the Sponsor and Project Manager need to work in partnership to achieve successful outcomes. In a PRINCE2 project, the sponsor is someone from within the business and is called Executive. Project sponsors are usually individuals with significant responsibilities and consequently limited availability. Yet, they are ultimately responsible for the project and therefore need to be consulted with effectively to ensure the project is likely to achieve the outcomes sought.

This requires effective planning and delegation of authority. The Project Manager is responsible for managing day to day activities of the project. The sponsor is not there to help on day to day matters. The sponsor is there to advise on direction of the project, help with organizational knowledge. One effective use of your sponsor can be to handle resource commitments from teams where the Project Manager is not a line manager. However, that should not delve into the management of individuals in the team. Levels of authority and tolerance should be set out in the Project Charter (PID in PRINCE2).

Preparation is key in establishing working relationships with project sponsors. Providing the status report just before the meeting does not augur for a productive Project Board meeting. At the beginning of the project the Sponsor and Project Manager need to establish the outline of the reporting structure. Reporting is likely to be different based on what the project is trying to achieve and what are considered the Key Performance Indicators. Ground rules need to be set out regarding communication procedures – when the reports should be sent, in what format, how risks and issues should be reported and escalation methods.

Trust is the basis for this working relationship. Communication needs to be open and transparent between the Sponsor and Project Manager. If there are issues in the project, do not hide from the sponsor – report Red as Red. If the issues are with Senior User or Senior Supplier groups then approach the Sponsor directly to appraise them of the situation. Bringing something to light too late in the piece will take away the Sponsor’s ability to influence outcomes. Uncertainty is usually what causes status reports to be rosier than what they should be. The Project Manager must agree with the Sponsor how uncertainty should be reported. Uncertainty, especially in the early stages of the project, is quite common.

The Sponsor’s exposure of the project is usually not on a continuous basis – usually monthly in large programmes. If everything goes according to plan, then this may be sufficient. However, it is a good practice to have an informal meeting with your sponsor in between status meetings. This ensures your sponsor is kept abreast of developments. Any issues from the project should not get through to the sponsor from other channels than the Project Manager. This will only serve to undermine the trust between the two. The Project Manager must also ensure what is submitted in written status reports correlate to what is being communicated informally in between the formal reports.

Involving the Sponsor is usually associated with something going wrong in the project. This does not have to be the only reason to involve your Sponsor with the project team. One of the speakers related how she looked forward to celebration of achievements in her projects and the ability to say well done. Although it was not necessarily the key message of the evening, it is one that stuck with me.

Project Manager runs the project on behalf of the Sponsor. The role of the Project Manager is to manage the project within the tolerances afforded to him. The role of the Sponsor is to enable that environment to flourish, so the desired outcome is achieved.

Image Credit: GlenKnight.Com

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 ensure continuous improvement?

As I sit back and relax for a few weeks, I have had the opportunity to reflect on some of the projects that I am currently running and the challenges facing them. I am getting back to work in a week’s time and now is the time to think about some new year’s resolutions that can improve my projects this year.

As a Project Manager, a majority of my working day is spent communicating with various stakeholders, internal and external. This comes with its own set of problems. I am sure I am not the only one facing the email hell. These days email has become the primary method of communication. So much so, that something written in an email is taken as an agreement, even though it may not give a total picture of a particular communication. Worse still, the constant stream of emails break the rhythm of any work and leads to many scattered pieces of work, rather than ordered tasks being ticked off as complete. As French tech firm Atos has found out, almost 90% of their emails are time wasters, that on reflection did not need a response.

How can I make sure I do not fall into the same traps again in the new year. I do not want to go as far as Atos in setting a goal to banish emails altogether. I have been thinking about checking my emails only 3-4 times a day and each time dedicating half hour to get through the lot. I have set myself a target of only sending small emails with a single topic. This makes it easier for the recipient to focus their attention. After all that is the purpose of all communication. I’m not going to aim for twitter length emails, but probably will try to limit myself to five or six sentences. If I am particularly interested in knowing if someone has read an email, I can always use the read receipt functionality in Outlook. If something cannot wait until my scheduled, it is obviously important and should be communicated through direct contact – phone, Skype or talking to them in person, where you have the undivided attention of the other party. When you think about it, there should be very few things that cannot wait a couple of hours.

Another dilemma I face is conducting meetings. This is true for both internal and external. There are cases where many attend the meeting, but do not contribute. In some cases too many attend and want to contribute. Dissenting opinion should never be squashed in projects. But neither should a meeting become a free for all. In cases where many opinions exist, it is more appropriate for each group to consolidate their positions and put forward a representative, so meetings can take place in an orderly fashion. I have found any more than six people in a room is a recipe for not getting a consensus and results in inaction. I have also decided to review before sending out each meeting invite, whether a direct conversation with the stakeholder can achieve my goals. That will ensure people do not sit idle during a meeting. I also plan to be much clearer on what I expect each person attending the meeting to contribute. This requires planning effort on my part to ensure any required reading material is provided in due time, allocations are made in people’s work schedules to look into the material etc.

I have seemingly taken on a couple of very simple improvement goals – get better at emails and meetings. In reality it is fundamentally different to the way I approach my daily schedule. I also recognize that small but continuous improvements has a higher chance of success, than radical ones. As the year progresses, I will review if I have indeed got better at this. I am quite keen to know what areas you are targeting for improvement.

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.

%d bloggers like this: