Abstract
More and more organisations are recognising project management as one of their core business competencies. These organisations are raising their level of project management performance and are seeing significant business benefits. They choose the projects that make the greatest contribution to the business strategy, and they execute them faster and cheaper, with less risk, and their projects deliver the expected business benefits. But many organisations are still at the beginning of this journey, and project management makes nothing like the contribution to business success that it can and should. Based on work with numerous clients and teams, this paper outlines key steps that low project management maturity organisations can take to improve their use of project management and gain big business benefits.
Introduction
The Project Management Institite (PMI®) A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines a project clearly and simply as “a temporary endeavour undertaken to create a unique product, service or result” (p.368). Organisations of all types are increasing using projects as tools to achieve their objectives in areas as diverse as new product development, business process improvement, organisational change, software development, property construction, regulatory compliance, outsourcing, merger and acquisition integration, and many more.
But research shows that project management performance is low in most organisations. The poor performance of many information (IT) projects has been widely reported. US consultancy Standish (2003) found that only 34% of business IT projects are successful, and accountants KPMG (2003) found that over half of the organisations they surveyed admitted having IT project failures in the previous twelve months, writing off an average £8 million each time. The Centre for Business Practices (2003a) found that over 80% of their respondents rated their organisations at level 1 (the lowest) on a five-level ‘project maturity model'. Using a similar maturity model, which they showed to be broadly correlated with project performance, PricewaterhouseCoopers (2004) conducted a survey covering over 10,000 projects of all kinds. They found that over 51% of the organisations surveyed were only at level 1 or 2, and that 60% wanted to increase their level of maturity and project performance.
This paper outlines seven basic project management practices that, in the author's experience, make the most difference for organisations starting their project management performance improvement.
Seven Basic Project Management Practices
Define the objectives and scope clearly
Define the business objectives of the project as clearly as possible at the start of the project. This sets the context for all that follows, and provides a clear point of reference for resolving issues. Also clearly define the scope (what the project will - and will not - cover), the major deliverables or products of the project, and the approach to how the project will be conducted and managed. By the end of the definition phase of the project, both what the project is about, and how it will be achieved should be clearly defined. This may sound obvious, but it is not uncommon to skimp or fudge these definitions in enthusiasm for the project, only to regret it later.
Engage users and stakeholders
Stakeholders include all the individuals or groups with an interest in the project. The key stakeholders usually include the Project Sponsor, other senior managers, and the staff affected by the change (e.g. the users of a new system), but may also include the customers and suppliers of the business, the managers and staff of related departments and functions, and others. Take care to identify all the stakeholders and ensure that they are engaged at all stages of the project. What this means in practice depends on the nature of the different stakeholders various interests in the project. As a minimum, all stakeholders should understand and agree with the objectives of the project and the overall plan, and be kept informed of progress. User involvement in IT and business process projects is crucial, because even if a project is delivered on time and on budget, it will fail if it does not meet the needs and expectations of its users. Users should be fully involved in all stages of the project - design, building, testing, and implementation. Good ways to achieve this are to second knowledgeable users onto the project team full-time, and persuade a senior user to help oversee the project by joining its Board or Steering Group.
Define clear roles and responsibilities
Everyone involved in the project should have a clear understanding of their role, and how it fits within the whole project. This includes users and stakeholders (who may be defining their requirements or reviewing deliverables for example) as well as the project team members who are executing the project and producing the deliverables. Most projects use an organisation chart to show the team structure and the broad areas of responsibility, but another useful device is the RACI chart which shows, for each deliverable or area of the project, who is Responsible (for doing the work), who is Accountable (for ensuring it is done), who should be Consulted, and who should be Informed. There should also be a clear governance structure for the project, detailing who has the authority to make decisions that are beyond the responsibility of the project manager, such as changing the due date or the budget of the project, changing its major deliverables, or even cancelling it. Usually this ultimate authority rests with a Project Board or Steering Group, chaired by the Project Sponsor and composed of key stakeholders.
Plan objectively and realistically
More projects are late and over budget because of poor estimates of how long they would take and what they would cost, than because of problems or mistakes during the course of the project (although that happens plenty too). Avoid setting a single figure in stone too early. Estimates of effort and cost should be expressed as ranges rather than as definitive numbers, and should be refined, and the range narrowed, as more information becomes available during the course of the project. The people responsible for doing the work should be involved in deriving the estimates as this helps make them realistic and achievable, and renders the “well I always knew it would take longer than that” excuse ineffective. The schedule, and thus the all-important end-date, for the project depends on the amount of work required and the number of people available to do it. This rule can be manipulated (more people = less time, although the relationship is not always that simple) but not broken. If a project is required by a certain fixed date, then it may be possible if sufficient people are available, but if the resources are also fixed, and at an insufficient level, then the end-date will be unrealistic and unachievable. Most, if not all, project people strive hard to meet their targets and deadlines, and they enjoy doing so. Nobody likes being behind all the time, or being without a realistic chance of success. Unrealistic and unachievable estimates and schedules erode morale and ensure failure.
Track progress and inspect the deliverables
The status of the project should be known at all times. This means measuring actual progress, and comparing it to the expected progress shown by the plan. Project staff find it very difficult to accurately gauge the completeness of a piece of work, leading to the dreaded ‘90% syndrome' where a deliverable is reported as nearly done, only to take a great deal more than expected balance to complete. One of the simplest ways to reduce this risk is to count only completed deliverables as progress ‘earned'. To do this, project plans should contain frequent deliverables, and the criteria for determining whether they are complete and correct should be clearly defined in advance (large deliverables to be broken down into smaller components, and the completion of these tracked in the same way). A project where there is a steady stream of deliverables, each arriving on time, on budget, and correct (according to the pre-defined criteria) is performing well, and likely to succeed. The non-completion of deliverables is an obvious warning signal, which is why they should be small and frequent, so that this warning is received as early as possible, and corrective action taken.
Manage risks, issues and changes actively
The key to minimising the impact of risks, issues, and changes is to manage then actively, using simple but effective processes. Risks should be identified, quantified, prioritised, and actioned - eliminated, mitigated or accepted - and reviewed regularly as they may change over the course of the project. Issues arise every day on projects, but there is no need to get bogged down by them. Keep issues visible by logging them, and making sure that each has an owner responsible for its resolution. Review the log regularly, and don't let old issues sit around - resolve or escalate the important ones, and close the others. Change control is a key process for all business IT projects. Flexibility is needed to meet evolving business requirements, but changes of marginal business benefit should be resisted. All proposed changes should be assessed for impact and benefit, and an informed decision taken by an authorised group (usually a ‘Change Board' or the Steering Group, depending on the scale of the change). Project members should not accommodate change because they think that it would be a good idea, or because one user or user group wants it. The logs of project risks, issues, and changes should be available to everyone on the project, since there could be impact in unexpected areas.
Communicate openly
Projects are highly co-operative and collaborative efforts, and frequent open and honest communication between all parties is essential. Outside of building systems for the government or military, there is rarely any need for any project information to be treated as a secret. Project people work best when they can see the whole picture, so information should be freely available. Communicating well with users and stakeholders is especially important. It helps manage expectations and ensures that there are no surprises during the project, or when it is delivered. Most business IT projects involve at least some organisational or behavioural change on the part of the those who will use it. Keeping users well informed with clear and open communication helps secure commitment to the change, and help ensure the desired business result.
Conclusion
The defining characteristic of low-maturity organisations is that project management processes are informal or inconsistently applied. The first initiatives undertaken by organisations seeking to improve their project management performance are usually the implementation of a Project Management Office (PMO) and/or the adoption of a project management methodology (Centre for Business Studies, 2003b). In the experience of the author, the success of these approaches depends on which processes are given focus and attention, how they are introduced, and the degree of organisational support. Organisations that introduce over-engineered project processes, and those where managers and sponsors accept superficial compliance (‘ticking the boxes’) rather than instilling real behavioural change, do not gain significant and sustained performance improvement. Those that concentrate their initial efforts on doing a small number of key processes well, and making them an integral part of the operation of the business see real benefits, and build a sound platform from which to improve further.
