Author: Neville Turbit

Overview

One of the most difficult parts of a project is to get buy-in from the business – in particular the Sponsor. This white paper explores a few techniques that can assist with the process. It also covers the engagement of business resources in a project and how that can be improved by a little bit of thought and planning.

Why Engage with the Sponsor

A good starting point is to ask why the Sponsor’s involvement is so important to the project. If you as a project manager are given a project to complete, why bother the Sponsor until you have completed the task.

The answer is that projects rarely run from start to finish without some sort of change or problem. Changes occur because the world does not conveniently stand still while we build whatever it is we are building. Problems occur because we don’t have perfect foresight. There will always be unanticipated events that will cause the project to change or be faced with difficulty.

It is at these times we need the support of the Sponsor. A decision, outside our sphere of authority may need to be made. We need support from the person at the top to get things moving in the right direction. In order to do this we need them to be up to date on the status and willing to break down a few walls that are too high for us to scale.

Getting the Direction Right

The other type of input we need is to make sure the project meets the business need WHEN IT IS DELIVERED. It may meet the need at the time it was initiated but what happens if the goalposts move? More importantly, who will tell us the goalposts are about to move? We need to constantly work with the Sponsor to ensure if the crane is coming to pick up the posts and move them, we know about it well in advance.

A related part of this is that a theoretical solution to a problem may not work out in practice. As the solution evolves, a better solution may present itself. A good example was some years ago I was working with a company to design a new factory maintenance system. They had looked at what was on the market but nothing was a good fit. They decided to build their own. During the build, we heard from an engaged sponsor who had been in South America on a business trip that a division there was building a similar system. As he was well versed in the local project he was able to identify quickly that it was a similar solution. He facilitated an exchange that resulted in a joint development. Had he not been so involved with the local development, he might never have found out about the one in South America.

The Starting Point

Before the project officially starts, I try to undertake a series of interviews with key stakeholders. These focus on five questions:

1. What in your view, is this project setting out to do and why?
2. Where do you believe we are up to now?
3. How will we know if the project is a success?
4. What do you see your role in this project?
5. Are you prepared to commit resources to the project?

Aligning Goals

The first two questions are meant to uncover differences on where people want to take the project, and what they believe is the current status. After discussing with a number of stakeholders, there is usually a difference of opinion evident somewhere. This needs to be resolved before you move forward. If it is not resolved, you are like a driver trying to go down both forks of the road at the same time. A crash is inevitable.

I was asked to assist a project to introduce a standard operating environment. The project was yet to get off the ground. I had two camps in terms of what the project was about. One insisted it was cost saving, and the other insisted it was improving flexibility through having more standard software on each desktop. The first camp wanted to reduce the amount of software on desktops and the other to expand the amount.

The second group said this could be done by having a number of standard software profiles. In effect there would be a multiplicity of profiles that would cost more to maintain. It took over six months to get the two views aligned. In the end, both gave up some ground and a compromise was reached. Had we started without resolving the differences, someone was bound to be disappointed.

The third question regarding the success is almost a logical follow on from the first two. If we are setting out to do something, how do we measure if it is successful? Remember that this is how your success as a project manager will be judged so be sure it is clear, and well marketed. You want the terms for measuring success clearly stated at the start of the project. No point in starting out in a 100m race to find out half way down the track it is really a 400m race.

Roles and Resources

The last two questions are about guaranteeing you get the resources you need. The first question

“What do you see as your role in this project?”

is really a trick question. Another example. I asked one mid level manager. His answer was

“My role is critical. I am the key player in all this. Whatever happens must meet my needs or it will fail.”

My response was:

“So you will certainly be a full time participant as we develop requirements, and probably manage the testing. We expect requirements will take around three to four weeks and testing two weeks.”

There was a pause. He answered

“I am far too busy to spend days away from the department to work with you. You will just have to fit in time around me to get sign off.”

My response was

“So you have someone you trust to be able to give us requirements, and they will be 95% right, then you will make time available to review and revise the requirements. It will add to the overall timing as we will be held up until you review and sign them off, but if you can provide a substitute, we can work around that by adjusting the schedule. It is not the fastest way to do it but if you are prepared to accept the additional delay rather than directly participate, we can work with that.”

In the end he was happy to give us more time rather than participate himself. Not only that, he gave us resources, and accepted that not giving us resources would cause a delay.

Be Specific about Resources

So when would you rather argue for resources? Before the project starts or just before you need resources? In the example above, we put forward exactly what we wanted. The discussion was not about the time but about who would do it.

Most salesmen are taught very early not to ask if they can get an appointment. Ask if Monday or Tuesday would be more convenient to meet. The question becomes a choice between meeting on Monday or Tuesday rather than a choice between meeting or not meeting.

Similarly with getting resources. Focus on who will be available for the period rather than if you need resources for the period. Consider the following two resource requests and decide which is going to work best for you.

• We and would like someone from your area to attend our requirements workshops over the next two weeks.
• Joe Smith’s experience is critical to the requirements workshops to be held over the next two weeks. We ask that Joe attends those workshops. If you think you have another knowledgeable person we would be pleased to discuss their suitability.

Agree the Skills First

Many times we end up with a resource, but the wrong resource. We ask for a representative of the business area and end up with a new starter. Did you really mean to say “we need a body above room temperature?”

When negotiating for people run through the skills and knowledge you might need and get agreement on those first. Then ask who might have those skills and knowledge. If you cannot find one person, perhaps a number of people may be required.

After you have verbal agreement, put it in writing and make sure it is clear that achieving deadlines is conditional on having the right people available. List the skills, and then confirm that the person you discussed the matter with confirmed that the nominated person fitted the role description.

Hooking the Sponsor

Having the Sponsor involved is essential as we mentioned. Explain in your first meeting with the Sponsor, what you expect from the Sponsor and why …. Except the other way round.

“It is important that we get everyone focused on how important this is to the organisation. We will have a number of people from inside and outside the company and if they believe it is low priority they will be hard to manage. To emphasize the importance, it would be invaluable if you could spend half an hour at the Kick Off to explain how you are absolutely committed to helping us achieve our objectives. That you will help us overcome any hurdles we might have to clear. When would be a convenient time to hold the Kick Off?”

Sound better than

“It would be nice if you can be there.”

The other key point is that the Sponsor is going to commit to supporting the project in front of the team. There is less chance of him or her backing away if they will loose face.

Project Steering Committee

Who should be on the committee? Essentially anyone who is likely to be an impediment. If they are made responsible for the success of the project, they are less likely to put a blockage in your way. If they do block you, they will be expected to un-block you at the committee level.

On one occasion I put a mid level manager on the committee. He had shown signs of being a blockage before the project even started. He was delighted to find himself in a forum with the senior managers. He thought it was an opportunity for them to see what a great person he was. Unfortunately for him, and fortunately for us, he had to move mountains in his own area to look good to his managers and make the project a success.

If you have senior management involved in the steering committee, don’t hold meetings just because one is scheduled. Make sure there are agendas, minutes and actions, and keep the focus on issues to be resolved. A good agenda is as follows.

• Brief overview of progress since last meeting
• Actions outstanding from last meeting
• Estimate to completion (any changes to cost, resources, risks, time or budget)
• Any changes impacting benefit delivery
• Issues requiring steering committee resolution
• Upcoming milestones

Escalation

Every project should have an agreed escalation path. It is a form of contingency planning. If something goes wrong, how do we solve it? Gain agreement from the Sponsor and Business as to who it is escalated to, and how quickly they are expected to respond.

For example:

If an issue cannot be resolved by the project manager, it should be escalated to the Sponsor immediately.

The team agree:

• Issues escalated to the sponsor will only be those that have a likely impact on time or budget for the project.
• All issues will be forwarded with the background documented, and options for resolution.

The Sponsor agrees that if an issue is escalated to the Sponsor, he/she will:

• Attend a meeting (personally or teleconference) within 2 days of receiving the issue.
• Consider the options presented and either make a decision, or resolve the matter within another day.

Satisfaction Survey

I owe this one to a colleague – Rob Posener. He uses this technique with Sponsors. Rob asks the Sponsor to rate their satisfaction with progress on a 1 to 10 scale. By tracking the figure you can get an indication of where there may be problems. As Rob says, if the Sponsor is consistently rating a 10, they probably don’t know what is going on!

The other benefit is that it gives the Project Manager an opportunity to discuss progress with the Sponsor. If the Sponsor rates it 9 for example, but there is a major problem looming, it gives the Project Manager an opportunity to discuss.

“Would you really rate it 9 with the current state of the infrastructure we are supposed to be installing on?”

Don’t show them a Spec

I have seen Project Managers say they are keeping people briefed because they forwarded a 200 page specification. I am yet to meet the person who reads specs all day. A better approach is to run a PowerPoint session outlining the key parts and try to identify any concerns.

If you absolutely need to get a 200 page spec signed off, stagger delivery. Deliver 10 twenty page specs and ask for signoff on each. In most cases, people like to get the whole package together before forwarding it. If one part is 95% right three weeks early, get it signed off, and then discuss changes at the end.

Understand the Business Cycle

I had to do a PIR on a project which had run significantly over schedule and was hardly considered one of the organisations finest achievements. One of the major delays had occurred in the user testing area. It seems the original plan scheduled testing in one particular month which suited the business. Unfortunately the following three months were the peak months for the business areas. When the project slipped, there was nobody available to undertake the testing for three months. The project spun its wheels for a few months.

The lesson is to get to know what the business cycle is all about. Know when peaks and troughs occur and build your plan to take that into account. This covers things like testing but also things like meetings and workshops.

Conclusion

Getting the required input from business areas will always be a problem with projects. Whilst a project team is usually a group of people given the time to undertake the project, a business participant may have the project on top of their normal job. Whilst the problem will never go away, you can lessen the impact by planning ahead. The ideas above have worked for me and can work for you.

Copyright Project Perfect