Tag Archives: Project Management

Project Planning – you need be sensitive as well as critical

Planning Process

In an earlier post, I suggested looking at planning as map-making for an expedition. Planning also requires elements of “Process Thinking” as it incorporates three key functions:

  1. Identification of all activities and constraints
  2. Development of the project logic
  3. Estimation of task duration

The key objectives are to identify the required sequence of events, assess the interaction between them and determine the overall timescale for the project.

Planning Problems

In my experience, three things go wrong in this process:

  1. Participants don’t fully understand the interactions between the various activities, especially the “virtual” constraints – where nothing physical happens (e.g. getting planning permission, awaiting drawing approval etc.)
  2. Over optimistic assessment of durations
  3. Fixation on the “Critical Path”

The Danger of “the Critical Path”

This may lead to over ambitious timescales being promised, excessive focus on a few issues and an over emphasis on physical activities. Often it is forgotten that the calculated “Critical Path” depends on the accuracy of the estimates of task / activity duration – change the estimates: change the critical path. Estimates by their very nature are approximate and therefore the impact of variations in these estimates needs to be evaluated.

In consequence a delay may occur when some virtual activity over runs, causing an activity well off the calculated Critical Path to affect the entire schedule.

What is needed, in addition to rigorous investigation is to undertake some sensitivity analysis and recognition that:

  1. Estimates are only estimates
  2. The implementation may take a different route to that planned
  3. You may be “fooled” by the technology – just because it looks neat on the printout, it doesn’t mean it will be plain sailing.
Typical Project Schedule

Project Schedule

It’s the quality of the thinking that matters

What matters is that you think about your plan effectively. Planning is about thinking processes not software.

For the sake of a nail

AFalling Rocks Road Sign common feature of delays in “virtual” activities is that durations can expand in steps, they can accumulate and affect broad sections of the project. The non-arrival of vendor drawings could prevent an application for planning permission causing a a scheduled council meeting to be missed. A delay of one day in one task may lead to a delay of a month or so in the next activity. You might term this a landslide, which emphasises the need to understand the landscape of your project rather than the route map!

You need to be sensitive to the potentials for delay and don’t focus solely on the calculated Critical Path. The real route will be different to the planned journey. Be prepared for the rocks that may fall in your way, you will need to find a way around them.

Advertisements

Project Thinking – not your usual 9-5!

This is the first of several postings on the issues and approaches that contribute to Project Thinking. It builds on the ideas in the “Think about it – 8 ways to enhance your thinking” posting. This issue has gathered a lot of attention as have some related postings:

Turning good ideas into effective action and

One small step – from good idea to effective action

So, I am publishing this material rather earlier than I intended.

There but for fortune …

Managing projects is not the same as managing production! Projects are not continuous; they have a start and [hopefully] an end. You only get one roll of the dice. This means that you can follow best practice, have a great team and do a good job of managing the project but still get a poor outcome. Your efforts influence your chances of success but you cannot rely on chance to even things out.

Conversely, sometimes the worst organised and managed projects will succeed.

The trick is not to be disheartened by the first case or fooled by the second!

It’s not personal, it’s business

Often project managers forget that their project, however important it is to them, is a means to an end, the owners do not want the project; they only want the outcome, asset or capability. This means that you need to maintain a focus on the business objectives as well as the project objectives. A project that meets its internal goals without meeting the business objectives cannot be a success – it may become a “White Elephant”.

Project and Business Objectives Matrix

All change!

We live in a highly dynamic world today and the business environment can change very quickly, so keep the business objectives under frequent review. Things will change dramatically over the lifetime of most significant projects.

As discussed in earlier postings, it is crucial that everyone involved is doing the same project. Without agreement on aims, objectives and scope there can be no concerted effort and factional pressures will hamper progress.

Don’t forget the process

Similarly, project managers are likely to focus on the content of the project: what is to be delivered or developed. To manage effectively, it is also necessary to focus some attention on the process and the context. In structured project management environments, the preferred methodology may set the process but a wise PM will keep this under review and keep evaluating whether the default approach remains appropriate in the light of developments.

Project Thinking First Steps

So, the first element of project thinking is:

  • Think about risk and probability – there is no average
  • Focus on objectives
    • Project
    • Business
    • Bear in mind the rate of change in the business environment
    • Think about
      • Process
      • Context and
      • Content

That’s not what I thought I was getting!

It’s a scene to send a chill down the spine of any project manager:

You are proudly showing off the asset you’ve worked for a couple of years to develop to the end-user, only to be greeted by “Oh! That’s not what I thought I was getting!”

How can this be?

What you’ve delivered meets the agreed specifications in every detail and still the customer is not satisfied!

It’s time to rewind to the development phase to understand what has gone wrong.

In many cases, the group which will use the asset is isolated from the project delivery team by a series of internal and external groups which are more focused on project delivery than the business itself. Even with effective procedures to define every aspect of the project, there is a danger that things will get lost in translation.

In most projects, there is a “one shot” transfer of end user requirements into the project team – OK it might happen a few times but fairly early on the input from the end user is scaled down. The project is then largely in the hands of “the techies” – engineers, architects, software developers etc. These groups are intent on delivering the best possible solution to the problem which has been defined in the project brief, User Requirements Specification or whatever you call it.

As the project proceeds, a plethora of new and more detailed documents, drawings, specifications, 3D Models, Schemas, Flow diagrams etc. is produced. These are intended to convey the requirements to other groups who are more and more expert in their element of the project. So they are formatted in ways that make sense to these groups.

Good project practice will ensure that these documents are circulated to the end-user who may even have responsibility for approval of the design. What is often forgotten is that the people involved are experts in something completely different: running factories, operating data centres, managing buildings etc. They are not experts in project management, design or construction, so there is a risk that they won’t be able to interpret the documents well enough to make informed decisions on the suitability of what is being proposed. They may also be overwhelmed by the quantity of information and miss what is important to them.

Knowing this, it should come as no surprise that from time to time what is delivered is not what was expected.

So, what can you do about this?

  1. Think about it from their perspective – what do they know about and what are they interested in?
  2. Think about the types of document are they used to seeing and aim to produce documents, mock-ups, prototype screen displays, sample reports in formats that will make sense to them, even if this means extra work. Take them to see examples of what you are proposing, they may not be able to visualise what you are proposing from the design documents.
  3. Be very careful in selecting the documents you want them to approve – don’t overburden them with detail they don’t need, aren’t interested in or don’t have the skills or knowledge to assess.
  4. Aim for a dialogue which allows a two-way flow of information throughout the project process.
  5. Most importantly, treat them as what they are – your customer, so be customer focused.

In short, put as much effort into describing the “asset” to its end users / future owners in terms they will understand as you put into describing to the implementers in terms they understand.

Project Planning – the 4th Dimension

Project plans are often thought of has having three key parameters:

  • Scope – what you plan to do and the standard you intend to meet
  • Cost / Budget – How much you intend to spend [taking all resources into account] and
  • Time/ schedule – How long you expect the project to take.

Different project types / styles and levels complexity require different levels of sophistication but the basic principles remain the same.

What I’ve noticed in many major projects that the proposed method of implementing the project is less well defined than the other aspects at sanction. This is a major error – not only to do the three elements mentioned above depend on the assumed approach but it is crucial that they are all mutually compatible and consistent. The four elements are in tension with each other, so altering one will affect all the others.

Tensions between elements of the project plan

There is a severe risk that the budget will be based on one implementation approach whilst the schedule is based on another. Simple examples of this can often be seen in TV property development programmes where, for example, – the budget is based on the developer doing the work whilst the schedule [and anticipated quality] is based on employing professionals. These assumptions are incompatible and problems are likely to surface as the work proceeds.

In professional circles, the risk of major discrepancies of this type is lower but can still exist, particularly if the development stages have not been based on effective dialogue [see an earlier post in this series – Make sure everyone is doing the same project.] This risk is heightened if the various elements of the plan are put together by separate teams with inadequate attention to communication. Similarly, there is a danger that the implementation approach will be changed late in the definition phase with assumptions being made on the likely impact on other aspects of the project. The nuances of assumed changes of approach can easily be missed and the implications of, for example, undertaking design work in-house rather than contracting it out can be underestimated.

Difficulties of this type can surface on seemingly minor sub-projects which become more important as work proceeds. There is a natural tendency to focus on major and critical items. This can lead to the team being blindsided when a significant minor but sub-critical element, which may have received only scant attention in the development phase, is delayed or cannot be sourced.

It is critical that the:

  • Budget
  • Scope / Standard
  • Schedule and
  • Implementation approach

Are all congruent with each other and prepared to an equivalent level of detail / sophistication. Saying “we’ll cross that bridge when we come to it” is unlikely to be good enough and is often a reliable predictor of problems ahead!

Getting the right budget – its more than just cost cutting

A few days ago, I got a reminder about what seems to be a very useful meeting being run by my engineering institution [Institution of Chemical Engineers] and the Association of Project Managers entitled “Budget, what Budget”[http://www.icheme.org/pdfs/BudgetWhatBudget2PMSGAPM10Dec2010.pdf] in London on 10th December. This focuses on the issues around getting the best budget for your project.

Whilst this is critical, I think it only tells part of the story.

I’ve worked on the front end of projects for many years and know that the initial budget is usually considered to be too high – the costs outweigh the benefits.

So it tends to get reviewed downward thorough a cost cutting exercise – Balancing the costs and benefits by reducing the costsI also know that much of the scope removed in this process tends to creep back in during or after the project – suggesting that it was really needed.

This got me thinking about whether projects are too costly or whether there is just not enough effort put into the justification process.

Balancing the costs and benefits by making the benefits more overt.There needs to be a balance between the two. Here are 10 tips to help you get the right budget for your project by paying attention to the justification process.

1.    It’s all about business

However technologically based the company is they only do projects to gain a business advantage. It may be to cope with changes in the business environment, to respond to competitor action or to meet their own objectives. If you are going to win support, it will be because of the strength of your business case, not the technological.

2.    Understand the process

Your business will have a set of policies, rules and procedures to authorise projects. These are designed to make sure that the right projects get approved and the right ones get rejected. If you don’t understand [and are not prepared to criticise] the process then you will struggle to make a winning case.

3.    Yours is not the only view

Projects involve many different groups, operations, maintenance, marketing, engineering etc. Each has a different perspective on what is important. If you are to win the support of others, you need to understand their perspective.

4.    See the big picture

Your project will be designed to contribute to one or more strategic objectives but may also contribute to other objectives. This may be intended or may be unintended. Make sure that all of the benefits of the project are allowed for in the analysis.

5.    Check sensitivity / assumptions

Virtually every project goes through a cost cutting stage in the justification phase but it is important to note that other assumptions contribute to the assessment of the feasibility of the project. Make sure you understand the contribution to each assumption on the feasibility of the project. Then concentrate your efforts on the right parameters.

6.    Understand the risks

Projects convey us from the present to the future; as a consequence they all involve risks. How you allow for the uncertainties has a big bearing on the outcome of the project. What you know is not that important, it is critical to understand what you don’t know and allow for that. Ideally, you should be using a structured risk identification and management technique.

7.     Don’t open the bidding too low

When the opportunity for a project opens up in our area of interest we naturally want to do all we can to ensure that it is approved and the investment comes our way. This tendency can lead us to suggest a low initial figure for the capital cost. The danger is that this will be cast in stone particular as the “± 30%” caveat we add is missed. It would be better to quote a higher figure and point out that there will be opportunities to reduce the costs. That way you are not painted into a corner.

8.     Value not cost

It is easy to focus on the cost of the various features of the proposed future asset and it is very easy to be drawn into drastic cost reductions to meet the approval hurdles. It is however much more important to concentrate on value and using creative approaches to achieve the desired results more economically.

9.    Market your ideas

However good your ideas are, they will only be accepted if you sell them to the other interested parties. This means spelling out the benefits in business terms [Tip 1] and tailoring your message to the audience[s]. You may need to use a different approach for each group. [Tip 3] You need to lobby for your ideas to be adopted; it won’t happen unless you take action.

10.   Don’t forget WIIFM

The easiest way to get people’s attention is to show them what is in it for them, so make sure that your message to each person or group is focused on “What’s in it for me”

Improving Projects – Make sure everyone is doing the same project!

One of the most difficult situations for a project manager to deal with is that point in the implementation stage where one of the future users of the facility realises that what is being delivered is not what they were expecting. Usually, this means that there has been a communication error at some point in the scoping of the project or a lack of involvement of a key stakeholder.

Because problems of this type only come to light during the delivery phase, they can be particularly complex to deal with causing rework with cost and time penalties. So it is desirable to avoid them!

Causes

The causes frequently go right back to the project development stages and the processes used to move from each participant’s vague notions of what is required to a structured definition of the project scope.

Key issues include:

1.       Range of participants

2.       Process and Procedure

3.       Thinking processes

4.       Language Issues

5.       Cultural Issues

Participants

Most projects involve a wide range of actors with different skills, objectives and levels of involvement with the project and the assets to be delivered. Some are involved with its ultimate use, some with the construction or development and some with its on-going maintenance. Others may only be involved indirectly.

The end users of a project to develop a manufacturing facility:

  • Production
  • Maintenance
  • Marketing
  • QA
  • Logistics

The project team may involve:

  • Design
  • Construction
  • Project Management
  • Architect

This may be the tip of the iceberg: with corporate management and external contractors also having an input. For other types of project, the titles may be different but the complexity remains. Each group is likely to have only a partial understanding of each other’s perspective and ability to contribute.

Process Issues

Many project development frameworks envisage the development of a brief [protocol, mandate, charter etc.] which is intended to encapsulate the requirements of the sponsors and ultimate owners. This document is then used to guide the project team through the development and delivery phases.

This one hit method can cause serious problems as it may take only a slight difference in understanding to send the project team on a different trajectory to that anticipated by the sponsors.

Similarly, if there is not a mechanism to probe the objectives effectively, there is a significant danger that the project will deliver the stated needs but not the real needs. Satisfying the project objectives but not the corporate or strategic ones may result in the creation of a white elephant. This is discussed further in a paper “Integrating strategic and project management” [http://www.fulcrum-management.co.uk/html/resources.html]  and the book “Project Benefits Management” http://tinyurl.com/3cmekm .

Thinking Processes

Each group comes to the project with a different level of understanding based on their knowledge, experience, functional expertise etc. This influences both their perspective on the project and their perceived needs and wants.

This is the essence of what Peter Senge calls Mental Models [See for example http://www.infed.org/thinkers/senge.htm ]. Each of us has our own mental model which allows us to interact with and interpret the world – they are all different so failure to recognise this is a recipe for misunderstanding, futile argument and stress.

Gareth Morgan in his excellent book “Imaginization” provides a superb metaphor for how this works – he presents a drawing of a pig surrounded by a number of different observers ranging from a butcher to a small girl to a Muslim. [See slide 15 of http://www.authorstream.com/Presentation/aSGuest8691-130499-2-gareth-morgan-product-training-manuals-ppt-powerpoint/ ] they all see the same animal but it conjures up different responses for each.

One side effect of these different perspectives is that the different functional groupings each develop their own shorthand and there is a danger that they may well use the same terminology to mean quite different things.

Understanding these different perspectives is crucial to the effective development of a shared understanding of the project scope.

Language Issues

Appropriate use of language is crucial to shared understanding; unfortunately, our meaning is often distorted by what we say and how we say it. The quotation “I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant”; sums it up neatly.

One of the key ideas in the field of knowledge of Neurolinguistic Programming is the concept of the metamodel. This describes how the ways in which we use language can lead to lack of precision in communication. A particular issue is the notion of “nominalisation” where we give a name to an abstract concept and talk about it as if it were real. David Kerr, discussed this recently in his blog http://www.watt-works.com/blog/nlp/useful-until-its-not-using-nlp-to-understand-what-works/

Different groups [and individuals] will use the same word for different purposes with the danger that they will superficially agree with each other whilst disagreeing at a deeper level.  An architect and a laboratory manager may have very different understandings of what is meant by “a state of the art laboratory”.

This may be compounded by national language issues for multinational teams, especially where people are working in their second [or third languages]

Cultural Issues

The way the organisation goes about its work and the behaviours it encourages or discourages may have a significant impact on the ability of the team to define the scope of the project. If the organisation encourages deference to experts and / or discourages questioning of management decisions then there is a significant risk that the proposed scope and implementation method will not be examined critically.

The more diverse the team in areas of expertise, geography and experience, the greater will be the danger of culturally led misunderstandings.

Solutions

The first step in “solving” these problems is to understand that they are likely to occur; forewarned is forearmed. Specifically, however the following actions seem to be relevant:

1.       Encourage participants to understand the background, needs and contribution of each group.

2.       Use a facilitative approach to encourage effective dialogue. This requires an air of independence, a broader set of skills and techniques such as those outlined in “The Fifth Discipline Fieldbook” and “The Dance of Change” [both P Senge et al]. The methods database of the IAF is also useful.

3.       Use approaches to encourage focused and well directed thinking such as those suggested by Edward de Bono.

4.       Be wary of agreement which seems to have been reached too easily – remember the Alfred Sloan statement to his board ‘Gentlemen, I take it that we are all in complete agreement on the decision here. Then, I propose that we postpone further discussion to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.’

5.       Put effort into ensuring that all participants are able to understand what is being proposed, don’t exclude them by using a medium they don’t understand – we will return to this in a later post.

6.       Remember the Second Law of Thermodynamics – the universe tends to chaos, effort is needed to create order. So work at it!