Busy!

Better to be too busy to blog than too busy blogging.  Still, I am lucky to be rushed off my feet in the current economic climate.  And on that topic, it's my take that things are indeed picking up ... a little.  Is new project work a baromoter of business confidence?  I think that up to a point it is, but it depends on what's motivating the project.  Still, the desire to work with independent consultants is definitely picking up.  In addition to our current clients we have seen an unprecedented rush of enquiries and a hike in pre-sales activity over the past month alone.  Bring it on!

And, the weather has been great.

High Impact Event Status

Last year Box Arrow took part in Global Entrepreneurship Week. We organised an event called Funding, Facilities and Support for social entrepreneurs in conjunction with The Hub and with UWE Ventures. Great news: the organisers of Global Entrepreneurship Week have identified our event as a High Impact Event! Thanks to everyone who came along and particularly Mariama Njie at UWE Ventures and Helen Ripper at the Hub who made it happen.

Shocking Project Overspend - Rural Payments Agency

Sometimes, even in my less cynical moments, I am still shocked by the failures of some public sector projects. File on Four on BBC Radio 4 recently shone their spotlight on the shameful antics of the UK Rural Payment Agency. Some numbers:

Original IT budget: £54m
Current IT costs: £350m
Fine from the EU for gross inefficiency: £280m
Additional staff costs: £304m including 100x specialists consultants costing approx. £200,000 each, per year, from our friends at Accenture.

Objective of this project is to pay 107,000 farmers between £10,000 and £20,000 annual subsidy.

The chairman of the Commons Public Accounts Committee, Edward Leigh, said "it would be frankly easier just to write a cheque for £10-20 000 for each person ... it's tragic."

Listen to the podcast here

I shall post a link to a transcript of the programme when it is available. It's a cracker. Also mentioned is the disaster of the NHS IT system and the late, over budget, not working, national fire service system.

Ten Tips on BNET

Ten Tips for Successful Projects, the short paper I did emphasising the benefits of a small amount of best practice done well, has been added to BNET UK. If you're a subscriber you can download it for free and, of course, it's on www.boxarrow.co.uk.

Tweet Your Project

In large corporate project environments, distributed teams are the norm. Although it is great if you have working on a project in the same room it doesn't happen often.

So I say use Twitter or put something like it on a server, and tell eveyone to use it - hashtagging their project name.

Then, from time to time, you can see which projects are trending and where those pesky risks and issues are leading you.

You can now follow Box Arrow, well me really, on Twitter

New Website, New White Paper, New Video

We just put a revised Box Arrow website up. There's a new white paper on Project Management as a Service and a video explaining the name and giving a bit of an overview of PERT for those new to it. I really like the new site. Check it out!

Lessons Learned: A successful implementation of a knowledge management system in a major law firm

Last week I was invited along to one of Bristol's biggest law firms to hear a presentation on how they had successful implemented a new Knowledge Management System. There was some interesting lessons learned which I noted down afterwards - despite the niche subject matter, these might be useful on any project, in any sector.

1. Get the non-financial benefits right. The project wasn't authorised on the basis of it's financial payback. The project wasn't set up to reduce overall operating expenses or generate new or additional revenue and, similarly, the value of the project wasn't measured in these terms. Instead, the non-financial benefits of the project were weighted against financial investment and the decision was taken to accept the risk.
   
   
2. Maintain senior stakeholder commitment throughout. The project team had the buy-in of the top team from the outset and, critically, maintained the buy-in throughout the project. In the early stages, an external independent consultant who had particular credibility with the board, had recommended the approach the project was intending to take and this cemented the top team's commitment.
   
   
3. Look beyond your industry sector. The project team looked beyond products targeted at their sector. They consider the entire range of knowledge management products and, in the end, chose a product and an integration partner that had subject matter rather than sector experience. This had the added benefit of generating real energy on the part of their integration partner as they were keen to establish a foothold in the legal sector.
   
   
4. Use proven project management techniques. The team used proven project management techniques to assist with key decision making, particularly in the area of selecting a product and vendor. The team used weighted scoring to particularly good effect in this respect (sometimes referred to as the Analytical Hierarchy Process). The presentation noted that this kept the decision-making stakeholders focused on priorities and that it depersonalised choices.
   
   
5. Align the organisation's culture to the implementation strategy. The implementation strategy was neither big bang or a phased transition. Instead, on day one, the new Knowledge Management System was available to all users alongside the existing system. This helped the project team gain acceptance for the new system in an organisational culture that is conservative by default. As a result, all users could clearly see the benefits on an ongoing basis of the new system.

The Sick Risk

This should have been entered in the Box Arrow risk log:

Risk: Key person in the organisation suffers painful complications arising from a routine medical procedure and is compelled to remain, largely, in bed whilst taking strong painkillers and antibiotics.

Impact: 9 (out of 10)

Likelihood: 1

Mitigation: Undefined

Controls: Unknown

Oh well. Here I am stuck in bed. I can't stand up for more than a couple of minutes without unbearable pain, I can't sit normally at a chair and I can't drive. Ho Hum.

Blog posts from now on will be significantly shorter.

Organisational Context 1: Corporates

I think it is interesting to reflect upon the organisational context in which project management occurs, the project culture. In the first of a series on project management contexts, here are some notes on the characteristics of project management in big organisations, e.g. multi-nationals, big banks, major telcos, big utilities.

• All projects follow a standard lifecycle. Is this a good thing? The implication is that the organisation believes it is appropriate for all projects to go through the same stages. A third-party project management method, e.g. PRINCE2, is often partially adopted or used as the basis for the in-house lifecycle. ( In reality, many organisations are “PINO” organisations – Prince In Name Only.) PRINCE2 includes the very useful stage "define project stages", this is often the first part of PRINCE2 dropped in corporates.
  

• A team of people exists creating and developing standardised templates for deliverables in a standardised project lifecycle. Often there is more than one team of people doing this e.g. for general projects, for IT projects, for property projects, etc. The people involved will maintain that there is great need for projects for different divisions and head office functions to have their own process. I think this is at odds with the first point, but it is common practice.
  
  
• There are numerous project manager-like roles such as business project manager, IT project manager, senior project manager, project leader, project portfolio manager, delivery manager, work-stream/package leader/manager. The individuals involved sometimes place great importance on the distinction between their roles, and at other times claim that any distinctions are meaningless.
  
  
• Aspects of project management are fragmented; it is not uncommon to find, for example, project accountants, implementation managers and project planners to whom aspects of project management are customarily delegated.
  
  
• There are usually several PMO or PSO functions providing support on project processes and cajoling project managers to deliver reports on time. Some people in these firms enjoy debating the differences between a Project Management Office and a Project Support Office claiming the differences are obvious. Some people will often talk, in hushed tones, of creating a “true” PSO or PMO, implying that current or planned PSOs or PMOs are false, or at least somehow not bonafide.
  
  
• From time to time, big organisations get completely fed-up with their in-house project managers and freelancers. They chuck out the freelancers and hand the whole lot over to a large management consultancy until, after a period of time usually longer than planned, they get fed up with the consultants and realise they have run out of cash. Eventually, like a collection of disparate migratory birds, the freelancers return to cheer up the demoralised staff. In all large organisations this process is cyclical.
  
  
• There is often an unstated assumption that project managers in large organisations know how to successfully navigate the organisation's project management method (see point 1). In my experience, and the experience of many great project managers I have known, project managers often have a nagging doubt that sooner or later someone is going to pick them up for not having done something which should have been obvious Sometimes this nagging doubt can turn into a general background of anxiety.
  
  
• Project Managers in large organisations have to contend with the make-believe paradigm of the internal market. More on that in another blog post.
  
  
• Project benefits, that is to say, the measurable outcomes delivered by the project, upon which the investment in the project was signed-off are often troublesome. Periodically, organisations tackle Benefits Management and when they get it right, it seems as if all projects are given a new sense of purpose. Unfortunately it rarely lasts long. Many projects excuse themselves from tackling benefits by describing themselves as “enabling projects”. Some organisation's internal project management gurus neatly side-step the issue all together by insisting that benefits aren't part of projects.

At the risk of sounding cynical, I have frequently observed that the success of an internal, corporate project is often not measured by the quality, timeliness and value of its deliverables, but by the extent of its compliance with the organisations standardised project process.

Next in Project Culture – notes on mid-sized professional services firms.

What if a meteor destroys planet Earth? A straightforward, structured approach to managing risk on projects.

At the start of projects, around the time of getting the business case agreed, it can pay dividends to start taking a structured approach for managing risk. I thought I would outline a straightforward approach that can be applied on a variety of projects, in a variety of businesses. The approach falls into three sections. Firstly, the risk workshop, in which risks are identified. Secondly, risk analysis, in which the workshop output is examined. Thirdly, risk review, which embeds risk management into the regular review of the project's progress.

But before we go too far with risk management, we need to be clear what we mean by risk. A risk is an event that may or may not happen in the future, which if it does happen, will have a bearing on your project. What are dealing with is managing uncertainty.

At the risk workshop ask people to brainstorm risks. What could happen that will knock us off track? What are the problems we have with finance, the IT department, the supplier? When you feel you have captured the majority of risks, ask the team to score them in terms of likelihood of occurring and impact on the project. Many people score risks high, medium or low but I prefer scoring on a scale of 1 – 10. Likelihood and impact are the start of risk analysis and it is very productive to score risks in the workshop.

After the workshop, the risk analysis begins. It is not enough to add up crude scores for likelihood and impact to identify the 'biggest risk'. The analysis needs to verify the relative scoring and consider two more dimensions; mitigation and control. If the risk occurs, how can we mitigate it's effect on the project? Are there contingency arrangements that can be put in place, for example? Control is crucial – consider how effective your management controls are in giving you early warning that the risk is likely to occur? If you have identified a risk that your key supplier might fall victim of the recession, how close are you to them? Is your relationship good enough that they will give you fair warning? Perhaps that supplier should be attending the weekly project meeting.

Someone may chuck in a “what if a meteor destroys planet earth?” to which the only reasonable answer is “we all get destroyed too”. Focus on the risks that the project team can manage and control the impact of.

Embedding risk management into the ongoing management of the project means adding a risk review to the agenda of every project meeting. It can seem pedantic to trot out the risk log at each meeting, but it is an important part of staying on top of uncertainty. Consider each risk, is it still relevant? Has anything new emerged that needs to be captured? Check that scores for likelihood and impact are still reasonable. Review the effectiveness of management controls and mitigation options.

A structured approach to risk management provides organisations tackling project work a number of key benefits over and above effective management of the project in hand. Risk management provides a language for discussing difficulties – it can swiftly de-personalise challenges that need to be carefully thought through. Risks logs also provide an organisation with the means to learn from experience. It is our response to uncertainty that distinguishes our maturity.

The things I have learned from the places I have worked

In 20 years I have worked for 13 organisations. Around 8 years of that has been in IT departments and the remainder on 'business transformation programmes' or in Finance departments. Most of my time with the organisations below was working on specific projects, or phases of projects. The shortest time with an organisation was a 6 week interim management role, the longest was three years. Some roles have been concurrent – at one point I was freelancing for a bank and teaching at two colleges.

I decided to note one thing I learned at each organisation. In chronological order, here we go.

• Massive central government IT department
  I am interested in computer systems, but not in massive central government IT departments.
  
  
• Small-medium sized software company
  Good projects are delivered by good teams.
  
  
• Business transformation services arm of a foreign government
  I am not as clever as I think I am.
  
  
• Major TelCo
  Respect your colleagues, even if they do work in Marketing.
  
  
• Major Utility Company
  The way that big consultancies integrate themselves into their clients is astonishing in terms of scale, sophistication and cost.
  
  
• Partially privatised national governement service
  A hard boss can be a good boss.
  
  
• Mid-sized law firm
  There are two sides to every argument, often more.
  
  
• The Insurance and Investment division of a major bank
  Senior management positions aren't that much fun really.
  
  
• A College
  There is no money in teaching, and not a lot of teaching.
  
  
• A specialist music college
  I don't like teaching teenagers either.
  
  
• Another major bank
  You have to manage consultants pro-actively.
  
  
• A global leader in financial services
  Some people could never succeed in small companies.
  
  
• Yet another major bank
  Have the confidence of your recommendations.
  
  
• The IT division of a major bank
  Process means nothing without service.

What I have learned from all of this is that there are three things I think you need to get right with work. Firstly, you need to respect the organisation that you work for. You need to feel that working for the organisation that you work for is something that you can take a little pride in, and you have to be able to justify that. Secondly, you need to feel satisfied by the work that you do. You need to feel that, on balance, you are going home with a feeling of a job well done. You need to feel that the work you do and you attitude to it means your abilities are being used well and developed appropriately. Thirdly, you need to enjoy the company of the people that you work with. In 20 years, I can honestly say that I scored 3 out 3 very briefly, many years ago, but since then 2 out of 3 has been pretty rare. However, I am fortunate in that with few exceptions I have always worked with great people.

Taking the advice of a friend I have edited this post removing the names of organisaitons I have previously worked for. Although there is no offence intended, at all, you never know how people will read things and I don't want to come a cropper.