Project Management PROJECTS ARE FROM MARS, PEOPLE ARE FROM EARTH Dominic Cooper The things that a bank needs to do to deliver projects successfully have changed. This change is partly down to the evolution of new methodologies, technologies, development techniques and planning tools. For example, knocking up an MS Project plan is now so quick and easy that mature adults carry them around clutched close to their bodies like security blankets, released only briefly to be used to rub sponsors' tummies along with the soothing mantra 'Oh yes, it's achievable, it's all here in the plan'. The cult of the quick project plan means that the Gantt chart has credibility, people believe it no matter how much or how little rigour has gone into its creation as long as the bars show a downwards and rightwards pattern. This is probably grossly unfair (on most people), but it serves to make the point that MS Project is a double-edged sword; it's just as easy to knock-up a bad plan as a good one - far, far easier actually. Web technologies have changed project delivery principles too. This is partly to do with the shift from functionality to infrastructure. Before, we used to write down what the business wanted and then make the system do it, now we build an infrastructure framework and then ask the business to fill it up with its operating rules, e.g. instrument attributes, posting rules, workflow, exception handling (this is similar to the shift towards an infrastructural approach that has been evident in MI projects for some time, the empowerment of users with desktop OLAP tools). And this is all fantastic, allowing the people who know most about what's needed to define how it works. The challenge to project managers now becomes to make sure the basics have been properly handled, because if mistakes are made they're more likely to be big ones (ah-ha, so we're missing an interface with the GL system!). So it seems that the more we move forward with new methods, technology and tools, the more the fluff around projects is removed to expose the core success factors, like; define the functional scope, understand the business processes, do the basic analysis and design well, and test rigorously. This probably applies regardless of the project scale, budget, complexity of requirement, and number of components/third parties. This tends to make things nice and crisp; if we focus on a small number of key tasks we'll be successful. And this is largely true, even if it is at the expense of an all round hike in pressure levels, because if things do go wrong, the questions are going to be particularly pointed. Dominic Cooper "it's just as easy to knock-up a bad plan as a good one - far, far easier actually" Another set of factors has changed what needs to be done to deliver projects successfully; the bigger picture perspectives on scope and measurement, like the shift from line roles to project roles as more and more people in banks are engaged full time on projects rather than performing operational tasks. This is the Change Management culture. Many banks are now split into 'run the bank' and 'change the bank' teams, where the 'change the bank' team comprises both operational practitioners and IT/Change experts. The terminology of project, programme, workstream and portfolio has also moved forwards (and backwards, and side-to-side too) and now the words mean different things in different banks. This can lead to confusion, especially in JVs, partly because the terms sometimes appear to be used completely interchangeably. In any event, the underlying principles are reasonably similar and the point is that there is a clear trend towards a programme management style, where whole operational departments are being managed as a change programme, part of which is a business-as-usual operational work stream. Measurement is not just in terms of simple cost/benefit, shareholder value effect is now the ultimate measure (weighted by the probability of success) and the capital/revenue implications need to be understood too. Project initiation can be a political art as well as a business planning exercise. Overall then, the challenge faced by banks in delivering successful projects has changed but many of the truisms remain, well, true. The golden rule has changed from; manage scope, time and budget to manage scope, time, budget and expectations. And this is right, it makes good sense. It's in the '10 easy steps to successful project management' box, the box that actually contains about 50 difficult steps, like: - Communicate, communicate, communicate - Make sure all the stakeholders buy-in to the objectives - Get the governance structure right - Work out the business case financials rigorously - Have a plan (right to left planning doesn't work) - Define success and deliver in phases - Understand the business model and align IT solutions to it - Develop processes and systems together - Documentation needs to be right - There is no such thing as an IT project - Be rigorous in analysis, design, component assembly and testing - Get the right people doing the right tasks - Use a project office to document agreements, control change (hard), escalate risks and issues to the right level, and track progress. - Control variance - Find it fast and fix it quick This is good stuff; they are all valid best practice statements. The problem is that they are easy to say but difficult to do, and even if they are achieved it's likely another one will emerge just too late. They don't guarantee success. But a project is made successful by its people even more than its processes. Only when best practice processes are combined with a set of effective behaviours will the project stand the best chance of success. These behaviours will probably never change no matter what scale or type of project, or which organisation it is to be delivered in (what will vary is the number and level of people for whom these are critical from a project viewpoint). As a rule these behaviours should be displayed by just about all project members, but are especially relevant for work stream leaders and project managers: - Push, push, push; to establish that the appropriate level of rigour has been applied. If people can articulate technical concepts or complex dependencies in cogent terms, it's a sign they are understood and will be handled well, if they can't then more work needs to be done. - Never assume things are happening; be hands-on in persistently checking and chasing progress. Unless something is nailed down tight it will come back to haunt you. - Be content rich; understand (learn about) the business context in full, don't fall back on project process because it won't be enough in the long run. Ultimately the success of the project may well fall on the shoulders of some 22 year-old techie fixing a bug or configuring a PC, and their success won't be as important to them as it is to you. Bluerock Consulting has undertaken a wide range of Programme and Project Management roles within the financial services sector. We have also performed a number of project risk assessments and undertaken quality assurance roles assisting clients with their business change initiatives. Dominic Cooper, a director of Bluerock Consulting, can be contacted on 020 7743 6780 or dominic.cooper@ bluerock-consulting.com