Defining your projects

The most important thing to is know WHY you want a project.

The most important thing to is know WHY you want a project.

Let’s follow on from last week’s blog on success and see what you can do to see if you are taking on board the messages. Successful projects need to lead to successful business outcomes and unless a project is adequately defined, it is unlikely to achieve anything, except perhaps a hole in your budget. Take any project that you are associated with and check that it is satisfactorily defined:

  • If you don’t know why you are doing the project, consider terminating it.
  • If you don’t know what you are delivering, regard your costs and timescales as unstable and your risk high.
  • If you don’t know when it will be done, carry out more investigations until you do know.
  • If you don’t know how you will approach the project, regard risk as high and investigate further.

“Project Definition” is a term used in The Project Workout, alternatives include:

  • Project Initiation Document or Dossier (PRINCE2)
  • Project management plan (PMI, APM)

Use this checklist to review any projects currently in progress.

  • Has a project definition been written, reviewed by the stakeholders and approved by the project sponsor?
  • Do the scope and objectives of the project meet the needs of the business?
  • Have the benefits been fully assessed and quantified wherever possible?
  • Do the benefits match the needs?
  • Have all significant risks been identified, categorised and taken into account in the plan and business case?
  • Has a comprehensive and satisfactory work breakdown been developed?
  • Does the work breakdown reflect the deliverables to be produced?
  • Are all key logical relationships between projects and activities clear?
  • Has the plan been developed to minimise or offset the risks?

The only way a project can be delivered is through its deliverables. For each deliverable check:

  • is the deliverables relevant and feasible both to produce and use?
  • Have quality criteria been established?
  • Is it clear who is accountable for preparing each deliverable?
  • Is it clear who will review the deliverable prior to acceptance?
  • Is it clear who will approve each deliverable?
  • Has sufficient time been allowed for reviewing/amending each deliverable?

For more on this see The Project Workout, Part Four which takes you through project set up and gives you some templates you can use.

Whose success is it?

In my “enemies within” blog, we looked at how management get the project performance they deserve. In that blog we explored the important role of the programme and project sponsor in making sure that an organisation’s programmes and projects succeed. But what does “success” mean? Success is too often interpreted through the differing eyes of stakeholders.

Successful project management ensures the delivery of a specified scope, on time and to budget (PMI’s triple constraint). It is related to how efficiently a project is managed. This should be assessed during the project closure review, documented in a project closure report and measured by timeliness of delivery milestones, adherence to budgets and quality. This is commonly associated with the role of the project manager.

A successful project realises the business benefits it was set up to achieve as stated in a business case. It is related to the effectiveness of the project in meeting the objectives set. The post implementation review (post-project review) assesses this. Measures of success here must be indicative of the business objectives being achieved. This review therefore has to happen some time after the output of the project has been put into use. It is associated with the role of the project sponsor.

A successful organisation drives towards its strategic objectives while fulfilling expectations of shareholders, managers, employees and other stakeholders. Measures for this are at a corporate level and should be financial and non-financial, such as a balanced score card. This is associated with the role of the chief executive.

A project which has been successfully ‘project managed’, however, may actually deliver little of value to the organisation. Further, a ‘successful project’ may not further the strategic objectives of the organisation, as its objectives may be out of alignment organisations seeking to optimise their total portfolio of projects through the effective combination of project management, sponsorship and portfolio management. A failing company can be full of ‘successful project management’ and ‘successful projects’ all driving in different directions.

The PMI’s recent report, Pulse of the Profession 2013, has actually picked up the above themes, so may this will help senior business leaders realise the potential that effective and efficient project management has to drive their organisations.

Gartner goes one step further and state that organisations which grasp this first will have a enhanced competitive advantage over the others.

Whatever you do must help you move towards your strategic objective. Otherwise there's no point.

Whatever you do must help you move towards your strategic objective. Otherwise there’s no point.

References:

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

Be a nut, be a leader!

Leadership

A leaders on his or her own is useless. There must be followers and the “first follower” is the most important, if change is to happen.

Do you think leadership is glorious? Is change totally dependent on the
leader? Do you think if a person looks ridiculous, they aren’t a leader?
Have a look at this video from Derek Sivers, I think you’ll enjoy it . . . and you might change your views on leadership:

See the Dancing Guy video.

So what’s the bottom line?

  1. If you are a version of the shirtless dancing guy, all alone, remember the importance of nurturing your first few followers as equals, making everything clearly about the movement, not you.
  2. Be public. Be easy to follow!
  3. But the biggest lesson here – did you catch it? – Leadership is over-glorified
  4. It started with the shirtless nut, and he’ll get all the credit, but it was the first follower who transformed a lone nut into a leader.
  5. There is no movement without the first follower.

We’re told we all need to be leaders, but that would be really ineffective. The best way to make a movement, if you really care, is to courageously follow and show others how to follow. So, when you find a lone nut doing something great . . . .

Have the guts to be the first person to stand up and join in.

Source: Derek Sivers; www.sivers.org

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

I thought you were doing that!

If you haven't got accountability right, you could look pretty stupid.

If you haven’t got accountability right, you could look pretty stupid.

Whenever I am called into a conversation on who’s accountable for this or responsible for that, things soon get out of hand as everyone starts to argue what “RACI” means and forgets about why they are there. By the way, it should be “ARCI”, but that doesn’t sound very nice.

Putting that aside, let’s look at this from a different angle, which looks at mind-set and behaviour. I came across this approach from a New Jersey company called London Peret Roche.

Accountable: what a person is accountable for; it includes WHO they are accountable to. If they aren’t accountable to anyone, they won’t be held to account and no-one will be counting on them.

Responsible: As a “grown-up”, I act responsibly. If I see a banana skin on the floor, I pick it up and put it in the bin, so no-one slips and breaks their neck. I wasn’t “accountable” for the banana skin; I merely acted responsibly i.e. as if I was the cause.

We all need to work together in programme and project teams and often are “counting on each other” to deliver or do certain things. If I spot something wrong in someone else’s area, I shouldn’t just ignore it, just because I’m not accountable. I should let the “accountable person” know and even offer to help them solve it, if I have the knowledge and skills needed. In programme and project teams we all succeed or fail together.

So let’s look at this in the context of a programme or project and see how this works.

The person who is accountable is not necessarily the person who does the work, but the one who sees that it is done. This is useful in planning projects. You should be familiar with the accountabilities of the project sponsor and project manager. The project manager is accountable to the project sponsor for managing the work on a day-to-day basis, ensuring the deliverables are in place at the required time, quality and cost. He or she cannot do it all, or in many cases manage it all. We all should also know how a project should deconstructed into life cycle stages. This decomposition can be followed through with major packages of work being made the accountability of a particular, named, team manager. These work packages may be divided into smaller work packages and ultimately into individual activities and tasks. This deconstruction is called a work breakdown structure. It is fundamental to good governance and planning and also forms the basis of reporting and escalations. So you see, accountability starts at the top and trckles down. If you aren’t clear on accountability, you have no governance in place.

In practice, single point accountability means every task, activity and work package at any level in the work breakdown structure has a person named as accountable for it. This has four advantages:
– It is clear what is expected of each person.
– Overlaps should be eliminated as no deliverable can be created within two different work packages.
– If a gap in accountability appears (due to loss of a team member, for example or a plain error), the next person up the tree is accountable to fix it.
– If scope, cost or time proves to be inadequate to create the deliverables, it is clear who is accountable for raising these issues.

In practice, accountability is shown in the way that project plans (bar charts) are designed. The examples given in the planning chapter (21) in the Project Workout, clearly show accountability.

In programmes and projects it is essential that accountabilities are clearly stated and are unambiguous so everyone knows who is called to account and who they are accountable to. Similarly, team commitment should be fostered, which promotes responsible and open behaviour by all team members. Knowing who is accountable is not about placing blame (blame games seldom achieve anything but angst), it should be about clarity over who is doing what and knowing who to talk to.

For more on tis see The Project Workout, Chapter 18, page 286.

Huge scale agile – a case study

Eating off the floor

There is often a debate about how agile delivery fits with other approaches and a conference I went to earlier in the year was no exception. In this conference, CMMI Made Practical, people were asking should we “do CMMI” or “do Agile”. This question mirrors the one I often hear about: “Should we do PRINCE2 or Agile”? It’s a question that actually misleads people. At the panel session for the conference wrap up, one panelist (me!) said that comparing CMMI and Agile or comparing PRINCE2 and Agile is a nonsense; it’s like comparing tables and chairs – they are different; but you can use them together, unless you want to eat off the floor”.

The distinction is very clear:

  • “Agile delivery” is done at work package level, with each sprint a representing a work package;
  • Each “Release” can be represented as a project stage;
  • Classic project management is the governance wrapper.
  • The early project stages are about business need, strategic fit and architecture.
  • The later project stages are about validation and deployment.
  • The agile bit is in the middle.
  • A project may comprise both agile and classic work packages.
  • Some good agile practices and are good project practices.

Taking classic and agile to an extreme

At that conference, I learnt about an organisation which had taken the above concepts to an extreme. I first came across it last November, but only realised who the company was at last week’s conference, when they presented their case study – SITA.

This is not just about software development but truly complex, platform based systems engineering. In other words it is something and large technologu based company might take note of and do some “health checks” on.

Here are some sizing metrics:

  • Distributed workforce in London, India, USA in  18 locations
  • Five primary system domains
  • 52,482 function points
  • Peak staffing: 703
  • Peak scrum teams: 61

So, it’s complex, distributed and off-shored. And in case you doubt it, this system does everything for 90% of airlines around the world before you get to the airport, at the airport, in the air and getting out of the airport, serving both the consumer directly as well as the airlines.

What is their key?

At the core of what they have done is created a classic project management wrap around agile delivery. They told me afterwards, that if anyone thinks they can do “agile” on this scale without without project management, they just prove they haven’t a clue. So what have they done?

At the heart is the Scrum, with its daily inspections, 2 weekly sprints and teams of about 8 people. A classic project stage is made up of 6 sprints (3 month long stages). They have the normal, input of prioritised requirements and an output of working software, giving them an increment in functionality. Within a sprint they do all the expected continuous integration and unit testing. In other words, good scrum stuff.

However because of the size and complexity of the system this is not enough. They have 5 streams of sprints going on at any time, with start and end points synchronized. They need to be able to draw these together and so before any agile development happens, they need to work through the requirements and prepare or update the architecture. Having a strongly managed architecture is key. Interfaces matter.

After the agile teams have delivered “working software”, there are four more project stages:

  • Non-functional tests, integration and performance tests
  • User acceptance test
  • Operational acceptance tests leading to delivery into production.

That is to say, it is a 7 stage project, with the third stage being agile (and sometimes the second also being agile).

The seven project stages.Source Presentation, CMMI Made Practical 2012, Lamri

The seven project stages.
Source Presentation, CMMI Made Practical 2012, Lamri

To make sure that the software coming out of the teams works, each team has a sandbox environment, which replicates the full build at that point in time to check actual interfaces. This means there are fewer defects needing to be trapped in the later formal verification stages. They say this is expensive on environments, but what is the point of writing something that either fails or simply won’t sit on the final hardware with everything else. As you can imagine, change control and configuration management are vital.

They have a core architecture team who continuously tune the architecture as more information emerges. Architecture is designed to minimise system interfaces. Often requirements for particular sprints are driven by this team in order to ensure interfaces are built in a co-ordinated way across sprints and that sets of software can be deployed in a useful way. Working software, in isolation, is useless software, unless it fits into a wider, usable application or system.  Inevitably there is rework resulting from changing architecture, so their sprints have time slots for making sure this happens. They are also clear with their suppliers that rework resulting from architecture changes are different to those resulting from poor workman ship. They expect 20 to 30 % rework but as a result of managing this, defects are trapped far earlier and overall delivery speeds up. They never leave rework for “sprint 6”, their last sprint. The approach of leaving all this until later in their view is counter productive.

Is it a success?

They say it is. By using their approach:

  • Their delivery schedule has reduced by 50%
  • Cost per function point down 43%
  • Defect density reduced by 40%

Sounds good to me; what do you think?  Have you any stories to support or challenge this?

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?