Project management excellence is not enough

Beware of doing too many projects, even if they do fit your strategy and have a good business case.

Beware of doing too many projects, even if they do fit your strategy and have a good business case.

The opening plenary sessions of the 2013 Gartner PPM and IT Summit in London, set the tone for a mind-set shift in how Gartner looks at “IT management”.  To date they have focussed in on “IT” and the “CIO”, and, in my view, perpetuating the gap between what they term “IT” and the “Business” . This year, to my delight, they were starting to talk about “the business” and IT’s part in it. It’s a brave thing to do, but the right thing to do. Most organisations still have their IT split off as separate organisational units ,with a separate strategy and loads of money, which tries to work out what “the business” wants and then all too often fails to meet those expectations. What is guaranteed though, is if you give an IT department money, they will spend it all, even if the business need is unclear. . . . that’s the “business’” fault!

Mike Langley from PMI was a key note speaker and gave his view on the all important question of “how do we ensure our (IT) projects fit our strategy?”  Notice I put “IT” in brackets – the department is irrelevant as we want all our projects to align with strategy . . . don’t we?

Mike based his talk on PMI’s recent “Pulse of the profession” survey.

We are all familiar with “strategy” and “execution” (sorry for using the “e” word, but when at an American conference, you can’t get away from it!).  The story is that the business leaders set the strategy and then the “business” implements it. If it goes wrong, it’s usually the fault of the business and their dreadful requirements and poor implementation!  What new research for Harvard Business Review is now talking about is that implementation is part of strategy and we should not separate them. (look out McKinsey and Bain!.) After all, if your strategy doesn’t include how to implement itself, then it’s a poor strategy.  The new buzz words for making this happen is “portfolio management”. This is a discipline of making sure that the programmes, projects and other activities that a business decides to do are the rights ones in terms of strategic direction, fit and balance in terms of risk and skills use. It’s all about selecting the right projects.

Mike says his research shows that organisations which are good at portfolio management are more agile, and have better project outcomes. Portfolio management is integral to how the top level leaders want to manage their business; it’s an integral part of business planning. Traditional business planning adds up costs of departmental budgets, checks against revenue and makes sure there is “interlock” if different departments need to work together.  Usually this is done a year or so in advance and is therefore totally pointless for organisations in fast moving environments. It is however a neat and simplistic way to blame people when things go wrong or costs to much. Hence, getting portfolio management working right is as much to do with mind-set as having the processes, systems and operating model.

Getting this right, means organisations can continuously tune their plans, not be tied to outdated annual budgets and use their people and money where the benefit is most attractive.  The money will follow the business need, not the department doing the work. Now that is what I call true organisational agility and if you have read the Project Workout, it will be very familiar to you.

This isn’t new as a concept, but it is something many organisations struggle with.  Have a look at this article: Excellence is not enough from the Project Workout “articles” web page.

The secrets of successful programmes

CranfieldI recently went to the International Centre for Programme Management (at Cranfield) for a forum on learning and knowledge management  and as part of that we were given a white paper called “Beating the odds – the secrets of successful programmes”.

The white paper describes the findings from a recent two-year study of 21 major programmes of many types, with varying levels of success in a wide range of organisations in Europe. Those findings explain many of the causes of the differeing levels of programme performance and how business leaders can improve the success rate for their own organizations.

Seldom do I read an article or paper with the words “Yes, yes, yes” ringing in my head. It is packed with useful insights and wisdom, gleaned for the programme teams who took part in the study. The wisdom in this paper won’t be found in methods and processes, they are more about how experienced and skilled people apply them and the issues they face.

I recommend this to any person who considers themselves to be (or aspires to be) a business leader. As expected, there is lots about vision, strategic alignment, business readiness, foggy objectives, stakeholder engagement, business cases, planning and behaviours. If, as a business leaders, you believe you have a great strategy, then good for you. On its own, however, that is not enough. You need to be able to convert your vision and your strategy into action on the ground. Do you have the right mind set, tools, methods to do this?  Read this article and decide for yourself.

This is the executive summary:

  1. Strategic alignment. From the programmes studied, those identified as integral to the future business strategy were all at least partially successful. It could be concluded that the ‘positive’ nature of the programmes’ intentions meant that there was little stakeholder resistance to the initiative and hence the organisation was able to deploy its most capable resources. Senior management and executive involvement was sustained throughout the programme. Conversely those programmes that had primarily ‘reductionist’ intentions, e.g. restructuring to reduce costs or eliminate inefficiencies, were less successful. Executive involvement in the programmes was weak and stakeholders’ commitment quickly waned.
  2. Need and readiness. Interestingly and perhaps counter intuitively, in most of the successful programmes the need was ‘high’ – clearly recognised as a business priority – but initially the readiness was ‘low’. In these the argument for investment and change was endorsed at executive level and time and effort spent at the start to achieve the buy-in of the rest of the organisation and develop the ability to undertake the changes. In the majority of those that were partially successful the readiness appeared to be ‘high’ as well as the need. Why they were not entirely successful is best explained as over-ambition or even over-enthusiasm; rather too many optimistic assumptions were made at the start with little assessment of the potential risks involved.
  3. Value drivers,benefits and business cases. The more successful programmes were also based on a clear strategic driver plus a strong financial business case. Those with weaker strategic drivers but good financial cases gained less commitment and were usually less successful. Very often financial benefits were overestimated, while the risks and the problems in making the changes were underestimated, perhaps because realistic estimates might have made it difficult to secure funds and resources. During the programme, as the scope becomes clearer, this inevitably leads to changes to the costs involved and the benefits that can actually be delivered, but only a minority of organisations revisit the business cases as programmes evolve.
  4. Foggy objectives. Programmes cannot be fully planned in advance and have to adapt to both changing business conditions and programme achievements. This is not necessarily a comfortable position for senior management and requires a knowledgeable, accountable and empowered governance group to oversee and, where necessary, adapt the programme. Rather than decrease during the programme, uncertainty can often even increase, especially due to changes in the external environment.
  5. Planning. Some organisations thought they may have ‘over-planned’ things at the start, due largely to the demands of some stakeholders for detailed plans, which were then not really used. However, the planning activities were seen as essential to bring stakeholders together and for reconciling their different priorities and interests. The process of planning was more important than the plans produced and helped address many of the initial uncertainties.
  6. vision and stakeholders. Having a clear vision of the intended future business and organisational models and then allowing compromises and trade-offs in the detail of how they are implemented, is more likely to achieve stakeholder commitment than imposition. The successful transformation programmes usually addressed the organisational, people and capability aspects first, before dealing with the process and technology aspects. The less successful tried to do the reverse.
  7. Learning and un-learning. Most ‘strategic’ programmes require the development or acquisition of new capabilities and knowledge in order to be carried out successfully. Management generally underestimate how much has to be learned by the organisation and individuals to define, manage and implement a major programme. Introducing new ways of working may also require considerable ‘un-learning’ by large numbers of professional people – not easy to achieve without actually removing the old processes. If the programme relies heavily on the capabilities of suppliers (especially IT suppliers), they may exert undue influence over what is done – the scope and achievable benefits – rather than on how the programme can be successfully delivered.
  8. Realising the benefits. Most business change programmes involve at least two distinct and different phases – first to create a new capability and second to exploit it. In most of the cases the new capability, for example a global HR database or Finance & Accounting Service Centre, was created, but not always used effectively, hence the benefits achieved were often less than those originally envisaged. While creating a new capability can be done ‘off-line’, separately from business as usual, using and exploiting it often competes with other operational priorities or can have negative effects on other aspects of operational performance, as was observed in some of the cases.
  9. Organisation and governance. Programme governance structures and staffing profiles are likely to change significantly over the life cycle. There seem to be three basic approaches to organising programmes: (1) a separate task force, (2) as part of business-as-usual (BaU), or (3) a combination (matrix). Not surprisingly the last of these proves most problematic. Some programmes have dedicated change managers, others have senior managers assigned to the programme, but they can find it difficult to reconcile achieving change at the same time as sustaining performance. Running change programmes in parallel with BaU causes tensions within the organisation and a clear statement of priority for which takes precedence is essential.
  10. Portfolio management. Few organisations, as yet, have the capabilities in place to manage multiple concurrent programmes with varying levels of uncertainty, competing for the same resources over extended periods. No organisation in the study had an effective mechanism in place for managing a combined large portfolio of ‘strategic’ programmes and more traditional projects – although some are trying to address this issue. Managing multiple programmes (Programme Portfolio Management) requires an additional governance structure or regular strategic and operational review and reconciliation at executive level especially if there are programme inter-dependencies or contention for critical and scarce resources.

Do you want to know more?

Cranfield had very kindly let me make the full article available to you here

So why was I saying “yes, yes, yes,” to myself? Many of the lessons are embedded in the Project Workout:

  • vision, strategic alignment: are covered in the gated approach to projects, from the very beginning(Chapters 3 to 11)
  • portfolio management is covered in Project Workout as “Business Programmes” in Chapters14 to 17.
  • business readiness,is a prerequisite for Project Workout’s Ready for Service Gate (page 118)
  • foggy objectives,are discussed in Chapter 12, along with other types of “Eddie Obeng” projects
  • stakeholder engagement,is covered in Chapter 19 as well as threaded throughout the book
  • business case, is at the heart of the Project Workout’s business led approach
  • planning in Chapter 19
  • behaviours are covered in Chapter 18

Of course, in the “real world” these are not isolated activities but happen in a complex network of cause and effect and that is why it is all so difficult to do in practice.

PowerPoint kills businesses – discuss.

If Romans had PowerPoint, would they have used it?

If Romans had PowerPoint, would they have used it?

This is a story about the evils of PowerPoint. It was first told by Edward Tufte, who some people consider as the most brilliant mind alive on information design. Tufte wrote the book on graphics theory, The Visual Display of Quantitative Information — and in one of his most intriguing  diversions has lambasted PowerPoint for being “a boil on human communication”.

Tufte explained how one horrible PowerPoint slide led to the 2003 Space Shuttle Columbia explosion — or more accurately, the horrible bullet structure PowerPoint gives us (and too many people use) caused the disaster. The problem is PowerPoint encourages writers to use clipped jargon that is hard to understand — and if the point fails, bad decisions get made. This is compounded by the fact that people often write grammatically incomplete sentences so that the meaning is actually impossible to determine . . . . all because someone wants it to fit on a bullet point line in a really big font.

As you likely recall, Columbia blew up on re-entry, after a large piece of foam broke off during launch and damaged the edge of a wing. Before the Columbia accident, foam had become detached during many other shuttle launches, so an internal report was crucial in determining how much risk the foam presented. Would a lot of foam detach? And could it hit the shuttle elsewhere with a lot of force?

In our businesses, this is what seems to happen:
1) People do a thorough analysis and write good reports.
2) The good report is then summarised into PowerPoint slides as that is “what senior management demand”
3) People find out that no-one actually reads their thorough reports and so stop doing them . . . perhaps also, even weakening their analyses.
4) Instead, they jump straight to creating a PowerPoint deck “summarising” something that doesn’t exist. (No one will find out anyway!)

Did you know that you can put far more good quality detail in a traditional two page “MS Word” report than on a 10 page set of PowerPoint slides? So why do we insist on using these as the primary way of communicating and as a foundation for decisions? Why don’t we simply use PowerPoint where it actually adds some value, rather than detract from it?

What’s your view?

  1. Do you LOVE PowerPoint and insist it is used?
  2. Is your organisation fixated on PowerPoint?
  3. Do you hate it but comply with our organisation’s flow?
  4. Do you have other ideas?

One theory I have is that strategy consultants traditionally use landscape style, slide decks for their “reports” and their clients follow suit, after all people like Bain  and McKinsey can’t be wrong, can they?

References:
You can look at a whole range of articles on the shuttle disaster here.

Or if you just have time to look at one, then read this one.

Enemies within – why it doesn’t work

Far too many projects fail.

Far too many projects fail.

Project management, in the modern sense, has been with us a long time now. Some people have spent most, if not all their careers engaged in it in one form or another. Research and anecdotal evidence, however, seems to indicate that we still don’t “get it”. Reports continue to be written on “causes of project failure”. Eminent committees are set up to “get to the root of the problem”, international and national standards are created and yet:

  • we still see failure.
  • we still see organisations which ignore the benefits.

Why is this? If I could answer that, then I would be able to charge massive consulting fees! The question is rather like that posed in “Hitchhikers guide to the galaxy” asking, “What is the meaning of life?”  As we all know, the answer is “42” – which doesn’t help us one jot. If I ever came across anyone who knew the solution to stopping “project failure”, I would be very skeptical.

So why can’t people grasp the significance and advantages of business-led project management? We have:

  • lots of good books – like the Project Workout!
  • National and international standards such as BS6079 and ISO21500
  • Leaned societies, like the APM and PMI
  • Conferences galore

Actually, when the Project Workout came out in 1997 it was probably the first to put project management in a business context; earlier books were focused on project management techniques.

Cover all four basesBack to the topic! Having good methods and process supported by good tools and systems with clear accountabilities is necessary but not enough. The critical difference comes from an organisation’s culture; how they behave and their values. Give me the right culture and mediocre process over poor culture and brilliant process, any day. Organisations where project management “doesn’t work”, are likely to have a culture which actively prevents it from working. For example, for project management to be effective, we need more than just good project managers; for example:

  • project sponsorship is vital if the projects are to be linked to strategy
  • portfolio management (called business programme management in the Project Workout) is necessary to balance risk and choose those projects which will get you towards your strategic intent faster
  • finance systems, which enable project sponsors, managers and teams to see, their operational figures “live”
  • resource management so you can take account of constraints in choosing and implementing your projects.

Hunter Thompson, in 1970, said “In a democracy, people usually get the kind of government they deserve and they deserve what they get.” In this he blames the people in a democracy. Organisations, however are not democracies and so I would turn that quotation on its head:

Senior teams get the project management performance they deserve“.

The CEO sets the culture and “the way they want to run their business” and the following list indicates where the culture and values promote failure, rather than success. Running a project is difficult enough, but we often make it more arduous than it need be by creating problems for ourselves. Here are a few examples:

  1. Reorganising – either the company or a part of it. Tinkering with your structure is usually NOT the solution to your problems, it just confuses people. If you are a senior executive, however, reorganising is a great way to hide non-delivery!
  2. Functional thinking – not taking the helicopter, the organisation-wide view. This often happens when executives’ or individuals’ bonuses are based on targets which are at odds with the organisation’s needs, e.g. sales bonus rewarded on revenue, regardless of profit or contribution.
  3. Having too many rules – the more rules you have, the more sinners you create and the less happy your people become. Have you ever met a happy bureaucrat?
  4. Disappearing and changing sponsors – without a sponsor there should be no project. Continual changing of the ‘driver’ will cause you to lose focus and forget WHY you are undertaking the project. Consider terminating such a project to see who really wants it!
  5. Ignoring the risks – risks don’t go away, so acknowledge them and manage them. If I said that a certain aeroplane is likely to crash, would you fly on it? And yet, every day executives approve projects when a simple risk analysis shows they are highly likely to fail.
  6. Dash in and get on with it! – if a project is that important, you haven’t the time NOT to plan your way ahead. High activity levels do not necessarily mean action or progress.
  7. Analysis paralysis – you need to investigate, but only enough to gain the confidence to move on. This is the opposite to dash in and ignore the risks. It is also a ploy used to delay projects: ‘. . . I haven’t quite enough information to make a decision, just do some more study work.’
  8. Untested assumptions – all assumptions are risks; treat them as such.
  9. Forgetting what the project is for – if this happens, terminate the project. If it is that useful, someone will scream and remember why it is being done.
  10. Executive’s ‘pet projects’ – have no exceptions. If an executive’s idea is really so good, it should stand up to the scrutiny that all the others go through. He or she may have a helicopter view, but might also have their head in the clouds.

I’m sure you can add to that list, so please do, by adding a comment. Over the next few months, I’ll investigate a number of the above symptoms.

In the meantime, you can find out more about these from The Project Workout (4th edition):

  • lessons on what works: Chapter 2
  • enemies within – page 41
  • sponsorship: Chapter 4
  • portfolio management: Chapters 14 and 15
  • resource management: Chapter 16
  • finances: Chapter 17

More on meetings

Are your meetings a bit like this?

Are your meetings a bit like this?

I did a blog on meetings last year, called I hate (some) meetings and one of the comments asked for some advice on conducting meetings. I suppose meetings are so common place that few people give any thought to making them run effectively. As a consequence, we find far too many meetings are an inedible waste of time. So, here we is some advice to take us back to the basics.

Firstly, do not hold a meeting at all if there is a better way of achieving the objective. The time taken during the meeting should typically represent only 10% to 20% of the total time needed to prepare for and follow up the meeting; use your time appropriately.

Before the meeting, the person calling the meeting should:

  • fix the objective, venue, date, time and attendance well in advance; keep numbers to a minimum
  • ensure all required parties are invited and have authority/knowledge to take decisions and/or make a valid contribution
  • set accountability and time limits for each agenda item, taking into account the participants’ different interest levels for each item
  • send out agenda and written submissions in time to allow participants to prepare.
    Those invited should accept the invitation, decline or provide a substitute attendee, as appropriate.

At the meeting:
The Chair should:

  • confirm who the note taker is
  • confirm the objective of the meeting
  • start and finish the meeting on time: censure late arrivals.
  • stick to the agenda and timetable.
  • ensure there is an agreed approach for undertaking each agenda item.
  • keep the meeting focused.
  • ensure full, participative discussion takes place.
  • guillotine “knotty” issues for resolution outside the meeting.
  • summarise each agenda item at the end and ensure agreements and actions are recorded .
  • agree and fix date for next meeting, if needed.
  • seek meeting participants’ feedback on the effectiveness of the meeting.

The Note taker should:

  •   act as the Chair’s right hand person.
  •   ensure all decisions and agreements are noted.
  •   take brief, relevant, action oriented notes.

Meeting participants should:

  • keep to the point and be brief.
  • listen to others and should not hold private meetings.
  • be constructive, adopting a “can do” approach
  • agree realistic plans/actions.
  • make a note of their own actions (including recipient and date).

After the meeting:
The Chair should:

  • review the effectiveness of the meeting and note improvement points for the next meeting.

The Note taker should:

  • publish the notes or minutes to the participants and those who need them within 1 day. What is the point of “old minutes”, they are no good to anyone. It takes the same time to do them straight away as to do them a month later – it’s just a matter of you organizing yourself.

Participants should:

  • assess their own effectiveness at the meeting and note areas for improvement; make suggestions to the Chair if appropriate.
  • read the minutes and address all actions and note those actions where they are the “recipient”.

HINTS
If you use a collaboration tool such as SharePoint or Livelink, use a task list to record the meeting’s actions. In this way, no actions are lost and those accountable for each action can readily find them.

Place “Review of Previous Minutes” towards the end of the meeting agenda, rather than at the beginning. This will encourage the meeting to go forward rather than starting by dwelling on what happened last time. If important, many of these items will be dealt with in the main agenda items.

If the notes are not for a formal meeting then consider the use of hand-written notes or as a photocopied page in your work book:

  •  record actions, in hand-writing at the meeting,
  • photocopy the sheet(s) just before the end of the meeting,
  • distribute to participants before they leave.
  • scan and file the handwritten note if you need a record.

. . . and make sure you all behave well at the meeting:

  • Start on time
  • Switch off or silence mobile devices
  • Keep to the agenda – Stick to the point
  • No private meetings
  • No interruptions or walk-outs
  • Be constructive
  • Speak out during the meeting – not afterwards
  • Be polite
  • LISTEN!
  • Agree conclusions and actions
  • FINISH ON TIME

PPM but not as we know it – learn from the Romans

Emperor Sponsus - visionary and leaderI am sure you’ll want to go home, put your feet up and forget about your programmes and projects for a while . . . but what if withdrawal symptoms set in and you have that urge to peek at your Blackberry or just take a look at that last report . . . help is at hand with a book extolling the virtues of programme and project management on the scale of the Roman Empire. Follow Emperor Sponsus on his path to glory and the trials and tribulations of general Marcus Projex Magna as he struggles to turn Sponsus’ vision into a reality.

This is programme management that you won’t learn about at Saeed Business School’s BT Centre for Major Programme Management in Oxford, nor from PMI or APM or MSP, nor anywhere else, for that matter.

Click here to download your cartoon book: How Rome was lost

Agile Delivery in Large Enterprises

There is no point in speeding if you are on the wrong road.

There is no point in speeding if you are on the wrong road.

Recently, I went to an “Agile Edge” conference at Valtech to hear Greg Hutchings talk on “Introducing Agile”. Here is what I learned.

You must know WHY you want to “do Agile”
The normal reasons people state for wanting agile are to:
– reduce time to market
– be more flexible
– be more efficient (less cost)
– increase quality.
All very laudable and valid reasons but Greg said there was one, less quoted, which he believed had the greatest leverage  – to increase customer intimacy. By working with customers, you build up a lasting relationship which can survive many of the knocks of corporate life. Business is, at heart, about people working with people. Efficiency is not generally a compelling case for Agile; flexibility and time to market are usually better. If you launch your services early, then your benefits flow earlier, often dwarfing the cost aspects (although costs centre accountants might not look at it that way!).

One thing Greg warned of was not to aim for all those benefits; you’ll just fail. His advice was to choose just one, then aim and focus on it; keep an eye on the others, but don’t let them drive you. He also warned that some things may get worse, but I am sure you “change-savvy” readers know all about that.

Who wants it anyway?
Greg’s key message was, if there is no-one in the Executive (top) level of the company who wants Agile, don’t waste your time. Successful implementations should initially come top down, with the senior leadership team signed up and then management trained on what it’s all about. You can then come bottom up with the training of the practitioners. Why? Agile relies on the right behaviours which, in some organisations, can look very strange or even appear subversive!  (See case study 2, later.)  You also need to make sure your sales force and customer services people are trained, so they can explain effectively to customers what Agile is all about. Finally, traditional contracts may no longer be appropriate as they tend to build in rigidity which works against the flexibility of Agile. Naturally, the customers also have to be involved; if they aren’t, you have no “customer intimacy” and Agile becomes futile!

Big bang or incremental adoption?
Incremental every time! In this way you have the space to “inspect and adapt” your approaches to suit your organisation. Greg did come across a company where they successfully implemented a pilot in three months and the senior leadership team was so impressed, the rest of the company was instructed to roll it out in the next three months. The manager commented that he did it . . . . but it was nowhere near as well done as the first tranche, as he was pushed to hit schedule deadlines rather than make sure it was right. It seems his leadership team had the view that new methods can be turned on and off like a switch. Will we ever learn?

There is no substitute for face to face working
One question from the floor concerned the trend for distributed, remote and home working. Greg was very clear that despite having wikis, teleconferencing, and all that stuff, there is no substitute for face to face work for critical activities. The hidden cost to an organisation of not letting people truly work together can be vast.

Case study 1 – FAILURE
Agile was implemented bottom up on an incremental basis. There was no top-down support. The consultants were removed from the company as what was exposed during the implementation work was too embarrassing for the incumbent Vice President. The implementation had no top down sponsorship nor effective governance. Most of the staff involved were fired. Six months later the Vice President in charge of the area lost his job for covering up some critical business issues. That company now has new leadership and is getting on much better . . . and adopting Agile.

Case study 2 – you’ll die waiting
The second case study is a large, global industrial company. They had executive sponsorship, a core team to implement it but very few people engaged in the outer global reaches of the company. After four years, they decided that Agile was a valid approach to IT development and may be used!

Case study 3 – A large telco – SUCCESS!

This organisation had executive sponsorship, a core team to lead and manage the implementation and good geographic representation. They focussed on product development but were careful to choose which developments in their portfolio would benefit most. They discounted the products at the end of their life-cycle, the cash cows and the highly innovative. They focussed on the others.

. . . . and then Greg ran out of time.

Summing it up
My own view is that I can’t see many customers wanting a fixed timescale and price for a variable output from their contractors. So, going in with the approach with an unconvinced customer may be dodgy. Often, however, a company will have many long term contracts which include “future services” clauses to cover stuff the customer wants but hasn’t a clue as to what the real requirements will be. Surely this is the opportunity space for using Agile?

I want to run an agile project

Agile. Do you remember that it used to be called “RAPID” but senior managers took that too literally and thought that if you want it fast, then use the RAPID approach to software development, regardless of whether it was appropriate. RAPID, soon become rabid.

Then it was called Dynamic Systems Delivery Method (DSDM) or something like that. Very memorable, just like all these acronyms. The sort of branding that makes people say “Eh?”.

Then “Agile” came along with its manifesto. Like the word “flexible” what senior executive or business leader can argue with it? They are not going to say “We want to be an inflexible and un-agile company”, are they? It’s great branding . . . . but do we have the same problems that the RAPID people had . . . perhaps – you let me know.

What happens to people who want to practice Agile in companies that don’t want it . . . or in companies which pretend they want it? Or, where the executive don’t really know what it is, but it sounds trendy? Have a look this video  and enjoy!

It’s a sad tale of a commonly seen situation, but frankly, I think the “Agile delivery manager” in the film, certainly wasn’t using the right approach to engaging his stakeholders. His approach is almost guaranteed to annoy even the most placid manager. At no point does he justify why an agile approach is a good idea in his situation . . . he just goes on and on, like a cracked record. He may have been right, but sometimes you need to be right in the right way!

. . . . . . If you can stand it, there is even a follow-on video on how the “(anti)hero” gets on in a new company, where he was recruited specifically for his agile delivery skills (he still seems to lack the required inter-personal skills though!).

Now, if you are interested in Agile and how it fits with “classic” project management, then let me know in the response and I’ll share some work I’ve done recently. I’ll even challenge to concept of an “agile project”!

Sponsors – ignore your stakeholders at your peril

Keeping stakeholders engaged can be challenging

As a programme or project sponsor, the formal and informal interactions with your project manager will probably form your primary linkage for directing a project. You should not, however, rely solely on this route for information gathering. Remember, benefits do not come from the project itself, but from using the deliverables and outputs the project produces – those who use the outputs are called stakeholders! Engage them and keep engaging them. Listen to what they are saying, how they say it, what they are not saying and observe what they are doing.

  • Are they walking the talk?
  • Are they saying one thing but doing the opposite?

Even a good project manager will not pick up all the ‘messages’ from stakeholders, so do not think you are undermining him or her by checking behind the scenes, especially with those all important, senior stakeholders.

Be particularly sensitive if people start withdrawing resources:

  •   for their “other” really important project’;
  •   because they have lost confidence in you;
  •   because another sponsor has leant on them.

Is this their way of blocking your project? Are their people really engaged and signed up to the solution, or merely paying lip service? Never underestimate stakeholders’ ability to ruin your best laid plans, especially in a “weak matrix” organisation! It is the project manager’s and project sponsor’s role to ensure all stakeholders are adequately briefed and engaged. Too much communication will drown them – they won’t bother with it. Not enough will mean your project will be lower down their priority list than you want it to be. Agree with your project manager which stakeholders each of you will target.

There is also a series of articles from Project Manager Today, on sponsorship, in the Project Workout community site.

I hate (some) meetings

I wonder how many people agree with the title of this article? In fact, I have not been fully honest; I hate badly run meetings. You’ve probably been there:

You turn up on time and hang around while others drift in. Someone spends the next 10 minutes looking for a chairman’s code so the “dial-in” attendees can participate. Then someone says, “Let’s start”. . . . . and everyone ignores him or her. Finally someone says, “Shall I chair this?”. “Oooo yes please”, comes the reply.
“Okay, what’s this about?”


SILENCE.


“Err, ok, lets look at the minutes of last month’s meeting. We got these yesterday, didn’t we?”
They all then go through some cryptic meeting notes and argue about what was really said. In fact for this one hour meeting, half of it is spent going over the last meeting. . . . with no progress at all and all the “agreements” made at the last meeting were disputed as the wording in the minutes was rather ambiguous.
“Sorry, I need to go”, says one person, “I have to walk the dog, she’ll chew the table legs if I don’t go.”
In a vain attempt to gain control the Chair says, “Let’s look at the actions from the preceeding meetings”. He then goes through them and they argue as to what the action really was and who was meant to do it. One action is done however, but no one can remember why it was needed or who the output was meant to go to.
“Ah,” says the Chair, “we are out of time, but could everyone stay on for another half hour? We do have some really important things to discuss.” He looks daggers at one person who walks out . . . .
He then lists the topics on a flip chart. The remaining attendees then discuss what order to take the “important items” in.
“Wasn’t there an agenda?”, says a new joiner (Aren’t they naive when they are young!).
“Oh no, we don’t go in for that bureaucracy. It’s such a waste of time. We always have the same agenda”.
They actually get through one item and then the meeting fizzles to a close.
“Well, that was good – we had that item sorted.”
“Did we?”
“Yes”
“Who got the action?”
“I don’t know; it’s not me any way”.
“Who was taking notes?”
“I don’t know. See you next time.”
“Who was on the conference phone?”
“I don’t know, we never asked . . . . “

I’m not sure if the story above reflects your reality or just pieces of reality; only you can tell, from your experience. In the meantime, if you end up in the “meeting from hell“, perhaps you can do something about it. and not be a victim. If you want , I could publish some “best practice” notes on meetings. Let me know.