Getting a clear result from the initial project briefing meeting is critical to a successful outcome - unless you get this part right you are wrongfooted at the outset, writes David Mascord

Ninety per cent of projects that fail do so on day one, according to project management gurus. Why? Because the business sponsor and the IT expert have not delivered an effective briefing. Parties may think they have agreed the same thing but the pictures in their minds can vary greatly. It is vital that project managers understand and clarify the brief fully if they are to deliver a solution the client really needs - not just the system the project managers think is required.

So, what can be done at the briefing stage to ensure project managers deliver an effective result?

Martin Bellamy, programme director for project management courses at Ashridge Business School, recommends making time for thinking and discussion. "Briefing is an absolutely critical stage. The temptation is to rush it because there is pressure to be seen to be doing something. No matter what other tasks they are involved in, managers should spend as much time as possible defining business objectives, scoping projects and agreeing deliverables."

Clear communication is a major factor. Project managers have to find a common language with customers and avoid technical jargon. "The sponsor must ask the right questions and understand the answers. The technical expert and sponsor must work together to seek clarification," says Trevor Cessford, financial controller for Bank of China International.

"Of course this will work only if both parties listen effectively and have open minds," he adds.

An open, positive environment also allows unforeseen problems to be raised objectively rather than hidden away. Those who have been through the bitter experience of a failed project put a "no surprises" approach at the heart of the communication between project participants. They recommend using the briefing to agree a mechanism for raising potential difficulties so they are brought out and dealt with objectively.

Another issue for any new project manager is the tendency to assume that because the sponsor is experienced in business it must know what it wants - which is not necessarily the case. In fact, managing the sponsor's involvement and expectations requires well-honed consultancy skills. This is where new project managers from in-house IT departments sometimes lack the experience of established consultancies.

"Manage the client," says Charles Mobbs, director at Fretwell-Downing Hospitality, which delivers software solutions to the catering industry. He advises using the briefing to establish the sponsor's involvement. "We always try to keep a senior user involved in the project from the outset," he says.

And, when it comes to handling internal or external clients, it is not just junior IT managers who have lessons to learn - dealing with internal politics is tricky even for skilled project managers. After all, it is tempting to avoid tough "people issues" when there are tangible technical issues to deal with.

If differing objectives and political in-fighting are apparent at briefing stage, they form a barrier that must not be ignored.

One of Ashridge's main theories concerns looking for constraints. If there is a constraint somewhere in a project, it says, whether due to resources, politics or timescales, resolving it must become a priority before progress can be made on the project. There is no point in wasting effort working on an area that is not constrained if some other factor is holding the whole project back.

Project managers are also advised, whatever their level of experience, to put dealing with other project stakeholders higher up their task list. Notably, they need to ensure during the briefing that the project includes a plan to consult end-users. Equally importantly, they should monitor the project team itself. A skilled manager will set the tone at the briefing.

When British Waterways agreed a £20m contract to integrate management information using SAP, finance director Mark Smith brought his project team together for an early briefing. "It was vital that Logica met British Waterways business managers to learn how the project fitted into business strategy and understand key deliverables," he says.

Clearly, with people issues and other factors to take into account, relying on technical knowledge alone does not make a project leader truly effective. An IT director at one government organisation says, "Some project managers believe that if you follow project management methodology, everything will be OK. They concentrate on method and don't spend enough time managing the process and people."

Principles, bar-charts and other project tools are useful, but they are there to support the process of business improvement rather than being the primary focus. Bellamy agrees. He sees the key characteristics of a good project manager as being a heightened version of those of any skilled manager. The effective project manager can use the briefing period to demonstrate these skills to the client and the team, in order to establish authority. "From the start, given the choice between technical knowledge and business skills, I would choose the skills of communication, leadership, and an ability to motivate and inspire action," he says."Most important is to have someone who is focused and persistent."

Five steps to better briefing

  • Do not over-rely on project tools
  • Be a good manager and consultant first, a technical expert second
  • Be aware of the strategic impact of the project on the business: identify who and what it affects and plan accordingly
  • Identify resources that are critical to the project's success and ask for them to be dedicated solely to your project - fight for what you need
  • Manage all stakeholders: business sponsors, end-users and project team members.

Seven golden rules
  • Ask what seem to be obvious questions. Clarify everything to avoid difficulties later
  • Do not assume the sponsors know what they want. Work with them to find a solution that meets their needs, rather than imposing one
  • Make sure you understand the purpose of the project
  • Define the business sponsors' involvement in the project - do not allow them to abdicate responsibility
  • Agree critical success factors and get the sponsor to sign off a project plan
  • Manage customer expectations - negotiate realistic deliverables and timescales
  • Never agree to something that is unachievable.

Case study: British Waterways team effort
With a £20m project to introduce a SAP-based integrated management information system at stake, Mark Smith, finance director for British Waterways, was not going to shirk the team briefing.

Following an initial session with senior British Waterways business managers and consultancy firm Logica, he pulled the full project team together at a one-day workshop. They heard presentations, clarified objectives, shared experiences and took part in team-building exercises.

Smith was also keen to establish his role at this stage. "It is crucial to involve a senior sponsor. I took part in presentations outlining British Waterways' 10-year plan. It was a signal that this is being taken very seriously. A senior Logica manager is also involved," he says.

He sees briefing time as an important part of the investment in a project. "The project had an 18-month gestation period. We wanted to get people together as soon as possible," he says.

"It was important to us that Logica had an understanding of what the business requirements were and also that the chemistry was right from a team development point of view. After all, 18 Logica people and 18 people from across British Waterways are together for the duration of the project."

<< Directors' notes
Why projects fail >>

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in February 2003

 

COMMENTS powered by Disqus  //  Commenting policy