Thursday 17 June 2010

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.

Saturday 10 April 2010

The six worst things I hate about lists

1. There is an annoying tendency of bloggers to resort to lists to connect random thoughts rather than writing a coherent article
2. Worse still they call it the “eight greatest..” or the “five worst..” and did they do any actual polling to find out which are the most important? I think not.
3. They have lots of similar points and don’t clearly distinguish between them.
4. They repeat themselves a lot and haven’t really thought through the points.
5. It would be OK if they were checklists that you could usefully use to make sure that you have done everything.. but they are not.
6. You get the feeling that the number of items in the list is dictated just by their attention span.

Monday 22 February 2010

Sorry seems to be the hardest word

I've been getting a lot of stick about my car. Jeremy Clarkson berates me every week calling me a "Pious Driver". But it suddenly got a lot worse. Now it's open season for Toyota drivers: first with the accelerator pedal problems, then with the brake problems on newer models of the Prius than mine, and now the steering on the Corolla.

I joined an internet forum to find out how to connect my bluetooth phone to the car and I get a cascade of comments: "that's the least of your problems" was the kindest. The poster slogan "The car in front is a Toyota" has graffiti "lucky it's not behind you".

So it was good to see Toyota president Akio Toyoda making a sincere bow of apology. I accept his apology.

It is the sign of a good leader to take responsibility for errors and failures of their team.  Then to fully take on board the lessons learned.

“FIRST, get the cow out of the ditch. Second, find out how the cow got into the ditch. Third, make sure you do whatever it takes so the cow doesn’t go into the ditch again.” This is the advice - quoted by the Schumpter business column in the Economist - that Anne Mulcahy, the former boss of Xerox, says became her mantra as she fought successfully to revive the fortunes of the copying and printing firm.

And I am talking about sincere apology too. None of this "SORRY. This bus is not in service." or spinning to play the issue down. You have to admit the cow is in the ditch.

To "do whatever it takes so the cow doesn't go into the ditch again" Toyota now offer a five year warranty, and their slogan in the UK is Your Toyota is My Toyota accompanied by pictures of a committed local workforce.

Some say that Akio Toyoda did not bow low enough. I say that we could do with a lot more sincere bowing for apology. Bow .. Sir Fred Goodwin. Bow ..Victor Blank. Bow ..Rick Fuld.

Tuesday 9 February 2010

It's time to kill big IT contracts

"I've met many programme directors who've said 'I'm doing a £100m programme', I say 'I feel very sorry for you'"

Phil Pavitt - the man in charge of the UK government's largest IT outsourcing deal - believes Whitehall needs to end its love affair with supersized IT contracts.

See the interview on Silicon.com : http://bit.ly/bRj2wU

Friday 8 January 2010

I have a cunning plan..

Building your project plan is the most critical step in any project. Your plan is the basic way of measuring the progress of the project - and if you can't measure it you can't manage it. If your project is to be successful it must start with a solid plan. Much of comedy of BlackAdders sidekick and servant Baldrick lies in the unachievability of his "cunning plans" and are there lessons to be learned from the succinct communication of his plans?
But how can we access the quality of the project plan before execution - or before it goes pear-shaped? Here are my "top three"
  • Completeness. Has everything been included? The best way to validate is through product based planning. You take the deliverable product and simply break it down into its component parts and assemblies (where there is some effort to put the parts together). So when planning a conference one area will be preparation of conference documentation - made up of component handouts for each session with the extra item of assembling the handouts into the conference binder. There should be activities corresponding to each component part and assembly.
  • Accuracy. As well as requiring a reliable basis for estimating the effort required for each task the accuracy of the interdependance of tasks and resources is critical. So a simple plan (below) to code and test a simple client-server not only requires the accurate estimation of each task - overrun of any task will cause a delay to the whole project -  but also the accurate scheduling of resources. The resource to perform task 2 needs to be available immediately task 1 completes to meet the schedule. Overruning task 1 will waste the time for the resources committed for task 2 - which may also be the same resources for coding in task 3? If the complexity of the data needed is underestimated that will extend not just the database setup but the middle tier, the user interface and testing. 

  • Socialising the plan. Most importantly the plan needs to be checked and committed to by everyone involved in the project. Too often the gantt chart will be produced by the PM - probably in Microsoft Project - and emailed out. However how are responses expected? Is there any narrative? Is there a list of assumptions used? Does everyone has the skills to use MS Project or even the software? So the ownership of the plan - and more importantly the committment to the plan and its accuracy- remains with the PM. Any mistakes remain the PMs problem. "I don't understand how the PM estimated this task so if I take longer then it's the PMs fault."
    To get commitment and belief in the project plan it needs to be "socialised" and fully communicated to get ownership by everyone involved. This communication needs innovative approaches - See Geof Lorys great "Lego My Schedule" and John Estrellas "How to create visual project timelines". But more importantly don't just depend on gantt charts; use narratives, brainstorming, risk workshops, feedback surveys or any way you can to get a true two way dialogue going to build trust and group committment.