The Global Project Managers toolkit

As you venture forth on a multinational project delivery, what tools you need to increase the chances of success?
As soon as you start to cross borders, the geographic and cultural separation mean that the trusted team management techniques such as "Management by walking around" and "the team that drinks together, thinks together" no longer apply.

Project Management.

A management process is essential for the success of any project. Let's face it: most Financial Services companies are very good at transactional execution but major projects are not their strong point. Project management is not about what you need to do on the project (see development methodology below) but how you control it:
•    Setting the scope and the business case for the project.
•    Identifying the tasks to be performed during the project, controlling the resources, managing the deliverables and quality.
•    Managing changes to the scope of the projects and risks.
•    Having gateway checkpoints and audits of the project.
•    Ensuring that the project meets the requirements, stays within budget and delivers the benefits.
Project management methods such as Prince2 and PMP are built around the core of the Executive Sponsor and the Project Manager. The Sponsor leads the project, makes the big decisions and assigns business resources the project needs. The project manager plans the project and is accountable to the business for the project delivery and achieving the benefits.
Software vendors and consultancies will, of course, offer to do the project management but Prince2 is very specific that the PM should not be from the supplier as they will ultimately be accountable to the supplier not the business, and introduce "lock in" with one supplier. Project management should anyhow start before the supplier is selected.
An international rollout may need broader programme management –providing strategic control of subsidiary projects such as the RFP process, software delivery and business change by country. Treating a multinational project as a programme can allow local project management and local accountability for achieving benefits.

Development Processes

There are broadly two types of development or implementation process:
The first, Waterfall - or "Big Design Up Front" – concentrates on gathering requirements at the start of the project, before going on to the traditionally more expensive design and programming stages.
The second, iterative processes, are widely seen as more suitable for package implementation and where there is business change going on in parallel, with requirements evolving through the project. They use prototyping, rough cut of configurations of a package, and pilots to test assumptions and refine the requirements. Each iteration can be seen as a mini project, which has a better chance of completing successfully and with measurable benefits coming out from each cycle.
The most highly iterative methods, such as scrum and extreme programming, where users and programmers are locked together in intense brainstorming and prototyping sessions, could be seen as less suitable for international projects because of the need for the team to be co-located, defining complex requirements like lease accounting and considering the collegiate requirements of different business units.
The implementation method is distinct from the project management. Where you are working with a supplier it is often best to use their methodology will be geared towards defining the specific deliverables for their system configuration..

Business Process Management

Many large organisations, particularly with manufacturing origins, will have their own Business Process Management or Re-engineering methodology – such as Toyota and Six-Sigma at GE. These are built around scientific calculation of the value each step adds to the end product. Many of these will be difficult to apply to financial processes – let's be mischievous and ask what value Credit add to a deal? – although Citibank in the eighties embraced the concept of "the bank as a factory".
In practice for systems enabled business change it will be better to build process redesign around best practice workflows provided by the systems supplier.
With a multinational implementation a single "cookie cutter" standard process can be difficult to impose, because of regional requirements, the different sizes of each business, and even particular individual talent.
But what is more important than the one-off process design is to develop a culture of continuous improvement across the operation with international sharing of best practice.

Collaboration Tools

Initial face to face team meetings are essential to build up trust and understanding at the early project stages. For teams that are dispersed for their day to day work it is important to use collaboration technology to keep them together virtually.
Audio conferencing (with local dial in numbers to cut down on cost) can be enhanced by web conferencing (using tools such as Webex or GoToMeeting to view presentations, whiteboards and even application demonstrations). Videoconferencing using webcams will work with these – up to a full telepresence if project budgets are that big.
Instant messaging is not just for teenagers and helpful to ping a quick question to a distant colleague. Email, although pervasive, is not best for project communications with long and intertwined email exchanges hard to follow. A central project document storage, intranet (shared within the organisation) or extranet (giving access to suppliers as well) provides a common project "knowledge base". Web based document storage or a Wiki (based on the technology behind Wikipedia) are now common solutions. Microsoft SharePoint 2010 adds the ability to have simultaneous editing of Office documents, publish and track project plans, create web based databases and even workflows from Visio diagrams.
And for the future, look at the demonstration Google Wave – think of a combination of instant messaging, email and a wiki.

Technology

For the global system itself what help is there from the technology? Microsoft's dotNet and rival J2EEE application development provide support for the basic number and date formats. But architectural solutions for the all the "multi" stuff has to come from the system design.
A web based application will certainly greatly assist with the deployment of the system over long distances than an older "thick client" PC application would allow. The amount of data displayed on the screen is improved with modern design and improved features like "type-ahead" make many web applications a richer experience than PC desktop programs.
Highly modularised service oriented applications speed system configuration by having "building blocks" to quickly support particular requirements. You also use web "applets" components to tailor your own screens and dashboards.
Virtualisation frees your application from being tied to particular hardware and servers. Software as a Service (SaaS) allows you to get software on a "pay per use" or utility model. If the software supports your needs this can be a quick way to set up and test software. On-going costs may come out higher in the long run but you are insulated from many of the hassles of in-house IT such as upgrades, and if things don't work out you have not lost the upfront investment! Make sure that SaaS software supports multinational requirements and don't forget that although it simplifies the technology delivery it doesn't take away any of the complexities of Business Process changes needed.
The logical conclusion of this is cloud computing, highly virtualised, highly scalable, internet based software. One note of caution is hidden in the terms of service of Amazon Web Services: "We strive to keep Your Content secure, but cannot guarantee that we will be successful at doing so, given the nature of the Internet. Accordingly... you bear sole responsibility for adequate security, protection and backup of Your Content and Applications."
Of course, while these tools can assist your international projects, in themselves they will not assure success. When combined with experienced practitioners they can leverage skills, reduce project risks and greatly increase productivity.
© Nic Evans 2010.

Lets Do The Risk Warp Again

In this trilogy of blogs (triblogy?) we have been seeing how some basic intuition and understanding of projects can lead us to manage and master risks. Dont think all these charts and graphs are any great theory - they are just a graphic representation of common sense!

Having understood the "cone of uncertainty" let us see what we can do to reduce uncertainty by warping it - bending the rules of project management.

Lets look at bending it three ways:

• Firstly let's reduce the long period between the user saying what they want - Requirements Specification - and being able to get a finished product and saying "Yes - That's It!" - Delivery Acceptance.
• Then let's compress the process to get to the requirements.
• And then let's compress the design and development process.

How?

• Use iterative and prototyping approach - "So is this what you mean?"
• By getting the user and the developer together - to avoid the risk of misunderstanding so well illustrated by the Tree Swing Design cartoon.
• By breaking the process down into small steps.

While this is has the characteristics of an Agile approach, many of these concepts have been around a long time. Iterative methodologies grew up in the eighties when PC development tools and 4GLs allowed programmers to design databases with the screens and reports in hours rather than weeks. They could talk straight to users and show them the programs to get feedback on the spot.

This develops into Agile methodologies where:

• Product definintions and requirements get cut down to brief "User stories"
• The requirements and design specification are replaced by scrums of colloboration between users and developpers
• Rapid development techniques allow the deliverables to be demonstrated to get rapid confirmation of the design

What does all this do to the Cone of Uncertainty?
Well the risk reduces:

• the time between design and acceptance is reduced.
• The risk will increase again at the start of each new iteration stage.
• The initial risk is also cut down because the early stages of definition are reduced to a high level description of what each stage is going to address.
• There is still some final acceptance. But this is reduced to what I would call integration acceptance - confirming that the deliverables from each stage work together.

So our Cone of Uncertainty is warped into the Christmas Tree of Collaboration!

What have we got to loose?

Let's develop some consequences of the cone of uncertainty - in particular the high risk and uncertainty at the start of the project.

All is not lost down the cone of uncertainty. Although the inaccuracy is high at the start, the stakes aren't high because you have no investment in the project.

We're talking here in general terms about a typical project.

You could see scenarios where you have to have investment or commitment right up front; where, say, you are committed to a fixed price delivery or have to meet some absolute deadline like a regulatory change (although in

such cases you would have requirements specified so you would be some way down the curve already).

If we look at the spending through the project (Shown in the second chart of cumulative expenditure - with the steepness of the curve showing the "Rate of Spend" ):

• Spending doesn't really start in earnest until you get into the main development phase of the project - when construction starts or the programmers start to cut the code.
• That's the point too where most of the project capital expenditure gets made, such as purchases of hardware and licences for the production environment.

If we put together the risk and the cost we end up with the Value at risk - or to put it in plain English -"What have we got to loose?"

This goes from the start of the project when the risks are highest but the investment is low. The value at risk then rises steeply as we progress; the spending rockets while the uncertainties and risks are still significant. As we reach the home straight the risk decreases. You will see that I haven't taken it down to zero when the project is delivered. Most phased project payment schedules will have a "retention" at the end to cover those snags that come up after delivery.

(Try that the next time you call out a plumber to fix a leak - "I will pay you 90% now and the rest when it has stayed dry for a month")

Let us not forget too, that for the user, delivery acceptance is only the start of the benefits that will come from the project, which will have risks too.

So what does this all mean for project risk management?

• If the project is going to fail it is best to let it fail at the start - and your early risk assessments should consider this.
• You need to have gateway reviews at the start - for assurance you have the governance in place.
• You then need to have reviews at the start of any project phase where the value at risk is going to increase.
• And you need to have project assurance all over the project through the main build/development phase when the value at risk peaks.

This, of course, assumes complete honesty and assurance that each phase is complete with the quality needed. So what if you start development -with its high spend rate - when in reality the requirements aren't fully defined? Well the simple maths says that you should apply the higher rate of uncertainty during the requirements specification to the higher spend during development and the value at risk suddenly rockets!

We've seen how by taking a few generalisations about a project we can quickly infer a lot more about the risks of a project. Let's go on to think about how we can bend some of these rules to our project advantage..

Planning Uncertainty

I came back to Mike Cohn's great book on Agile Estimating and Planning. The Agile Manifesto that values responding to change over following a plan doesn't at first seem to warrant a whole book on planning. It still needs to be done - as well illustrated by his quote :

"A good plan violently executed now is better than a perfect plan executed next week." - General George S. Patton

The book starts with a useful tool for any project manager - "Cone of Uncertainty":
This clearly shows what we all know:

At the start of the project, when we don't know exactly what needs to be done, our estimates for the work to be done are the least accurate.

Unfortunately for the hapless Project Manager it's at start of the project, when the business case for the project is being prepared that accurate estimates are most needed!

Different authors give different vertical scales to this cone of uncertainty, with the upper extreme of estimate accuracy (or should I say inaccuracy?) varying between 1.4 and 4. Some (as I have) also skew the uncertainty toward the high end - on the basis that most things get more complicated, rather than easier than expected.

So what are the lessons for the project manager as he gets drawn into the Cone of Uncertainty?

• It is essential to communicate to the project board and stakeholders that the initial estimates are inherently less accurate.
• It is good advice that project managers should always qualify any estimates with a probability: "There is a ninety percent chance this phase will be delivered ontime" - although you may get a reputation for avoiding commitment to deadlines if you do this too much!
• It shows that the milestones/project checkpoints, particularly before the start of detailed design and development, are essential steps to re-estimate costs and the business case, before committing to the increased expenditure as you get down to detail.
• If you have a project contingency budget to cover this early uncertainty you may need to review that contingency as the estimating improves, so it doesn't get spent "covering up" other issues that arise later.
• It is not an excuse that you should leave all estimating until the end of the project so it will be 100% accurate!

Risky Business

Here's a great white paper on project risk assessment in the context of corporate risk appetite.

http://www.projectperfect.com.au/white-paper-a-different-view-of-project-risk.php?b3note=riskmat

Unfortunately it doesn't extend onto management of project risks.

The Office Of Government Commerce also has some really useful risk potential assessment tools and techniques . They even have the spreadsheets set up to save you the math!

It just a shame that too many UK public projects don't stick to these principles. It is a major victory for common sense, the UK tax payer and for students of project management that Gateway Reviews are now published under Freedom of Information.

Whatever your views are on Prince2 there can be no doubt that its approach to project risk management is a sound framework. It will be interesting to see how the new guidance for Directing Successful Projects with PRINCE2 2009, aimed at project executives and sponsors, will clarify the project directors vital role in risk management.

How long will it be before this guidance has an impact on the Gateway Reviews?

Increase Sales! and other lies to justify IT

"The website for the ten million pound sales campaign with this partner will take just two days effort to develop!" appealed the sales leader to the Star Chamber for technology project justification.

"This is not going to increase our revenue by one pound" said the CEO. "Our web developers' time is better spent on other projects. Next proposal..."

The CEO was right. The addressable sales opportunity was not going to get any bigger because of the website. The website was not going to reduce the sales force assigned to the program.

It is all too easy to justify benefits as simply increased sales. It is the easiest way to get a big number on the benefit side. And the easiest trap to fall into for a business case.

(A search on Amazon shows that there are 127 books with "increase sales" in the title, bought by sales people who justify the purchase as "cost £20, benefit increased sales".

They are written by very canny salespeople who have discovered the benefits of scalability: If they sell then their income is limited by the number of hours in their day. If they write a book on selling then their income is no longer limited by their time but the marketablity of their ideas.)

So if you use "increased sales" as one of your benefits look long and hard at it.

• The benefits of the process improvement are not the total sales increase – but the increase in net revenue, after allowing for the full cost of sales and marketing and all other overheads.
• It is essential that there is a clear link between the increase in sales revenue and sales process improvement. It is not enough to attribute the increase in sales revenue in the current year to the process change. You should provide some firm and auditable types of deals or specific sales that can be justified and backed by sales management - who will need to ensure that the specific sales revenues have not been double counted for benefits or commission elsewhere.
• If you have an innovative sales channel then you need to make sure that you allow for any loss of sales revenue from other channels.

If you don't have the specific link from the process improvement to the benefit the risk is all to clear in the current economic climate: The process is implemented but because of the global recession sales fall. Now where is the benefit in that?

Anything is better than what we have..

When building a business case for a project it is all too easy to go for your first option.
OK, you haven't said its a "no brainer" and got the differences in cost, and the shiney benefits.

But with some thought you can justify anything.

But have you included the full costs, and factored in all the risks, in particular the implementation risks. Would a five percent increase in the development costs, or a three month delay to implementation, wipe out the benefits?

More importantly have you looked at all the options?

• An hour brainstorming with colleagues will come up with some different approaches.
• 30 minutes googling will get you a list of alternative suppliers.
• Two weeks for a proper Request for Proposal will be worth the investment in most cases. Get the full list of your business requirements and then put weighting on each.
• Don't just look at improving the efficiency of your current business processes. Option B may offer business transformation opportunities or a new sales model.

USwitch is a price comparison website for utilities, credit cards insurance, phones. And of course it will always find a lower priced supplier. But is it the best for your particular case ? - not the option that pays them the highest commission. When picking a phone supplier it will give you the cheapest local call rates or low cost inclusive minutes. But will you use all the inclusive minutes? And what if you make regular calls to your aunt in Australia?

Obvious? Just do the same for your business case.