An Environment for Managing Your Portfolio
The tools to help it work – systems
Lists – keeping tabs on your projects
What would such a system look like?
Some organisations are well on their way to managing themselves ‘out of their functional boxes’. Most are not.
‘I’ve got a little list. I’ve got a little list.’
W S GILBERT
In this chapter I will look at the type of environment you need to have in place around your projects and throughout your organisation if a projects approach is to succeed. You should now have a feel for the way a project progresses through its life cycle (Part Two) and how the wider decision-making framework can be organised to help you choose the right projects and not overcommit your resources.
In Chapter 2 we saw how any process does not sit in isolation but in the context of the structures, culture and systems you choose to wrap it in. In this chapter we will look at structures very briefly and then at the systems.
New structures for old
The whole approach for projects is to enable you to deploy the people you need anywhere in the organisation where they can, due to their mix of skills and competences, add the greatest value. The objective is to break through functional and departmental barriers to the extent that the word ‘cross-functional’ becomes unnecessary. In effect, your functional structure – which was so important in the ‘old days’ – becomes secondary to the key business programmes and projects which work across it. In such an environment, reorganisation, as a means of responding to problems, becomes less necessary (now what are the new executives going to do to prove they’ve arrived?). See also cartoon on p. 41.
The power base of the old functions was that they held the people, the budgets and any decisions within their domain. Often these were decisions which should have been taken on an organisation-wide basis. The power bases of the new organisations will be more associated with the roles of people and groups. Consequently, the important structures will be those associated with project sponsorship and decision-making bodies; these are the people and groups which will carve out the future shape of the organisation. They will be more associated with directing and coaching than managing. In fact, one could conceive of an organisation where the traditional ‘director at the top of a function’ is no longer deemed to be a sensible arrangement. When it comes to ‘direction’, we should be directing whole organisations and not just parts of it. Of course, every function needs a ‘person at the top’ to ensure that the work undertaken is of the highest standard, that people are happy and the ‘architectures’ are robust. However, just because someone is an exceptional people manager or gifted technical expert, it does not mean he/she has the breadth of knowledge, skills or competence to direct a corporation, or even that he/she wants to be a director! The corporate world is full of people promoted beyond their levels of competence, through no fault of their own.
Some organisations are well on their way to managing themselves ‘out of their functional boxes’. Most are not. The decrease in importance of functional hierarchy is not going to happen by someone merely decreeing it. It has its place and its uses. Much of the day-to-day work in many organisations is ideally suited to departments, provided the hand-offs and process flows are efficient and uninterrupted. It’s when it comes to change that the problems and limitations become apparent. Before you let go of the reins of traditional cost centre management, you need to build alternative communication channels, management frameworks and systems. You cannot ‘fly blind’. Once in place, they will be so useful that the old hierarchies will naturally decay, fall into disuse and become less relevant.
An organisation ran itself on a full matrix. It knew all its costs both by cost centre and by project and activity. It had had a stabilised structure for many years but finally decided that the emergence of new disciplines and a more unified approach to the market required a reorganisation of departments. This took about three months to put in place. However, financial reporting and work continued as usual as mostly everyone was working to a set of roles relating to prescribed accountabilities. The fact that there were no departments for a while made little difference to day-to-day work or reporting. They were already used to crossing boundaries.
Support offices
Leadership – from the top
If you are serious about enterprise-wide programme and project management you must realise that it doesn’t run itself. It needs leadership to establish its profile and to enforce the accountabilities. The opportunity may have been recognised by a few middle-management enthusiasts in various parts of your business and they may even get as far as agreeing some common methods and practices (PRTM Level 2; see p. 482). However, that is not enough if you are to reap the full rewards. You will need to have the following:
- Someone with top level accountability for the adoption and direction of the full environment across the whole organisation, preferably reporting directly to the CEO, deputy CEO or COO. I will call this a Programme Management Director and provide a typical set of accountabilities below.
- Someone with specific accountability for the architecture (accountabilities, process, systems and culture) of project management. I often refer to this person as ‘programme/project management design authority’ and provide a typical set of accountabilities below.
- An organisation to support these people in undertaking their roles. After all, you seldom find directors at this level doing all the detailed work themselves. I call these support offices.
The Programme Management Director is accountable to the chief executive officer for ensuring that all business change is planned, directed and managed in an effective and efficient way using appropriate programme and project management techniques.
Programme Management Director
- Championing good value business programme and project management and a benefits-driven culture.
- Introducing, maintaining and improving common programme management framework, process and methods, including for business planning, project selection and project authorisation.
- Creating an environment in which business programme and project managers and teams are developed and recognised for their skills.
- Recommending changes to senior management to improve the effectiveness and efficiency for delivering business change.
- Providing independent reviews of projects.
The Programme Management Design Authority is accountable to the Programme Management Director for acting as guardian for the organisation’s ‘best practice’ methodology, processes, tools, systems and templates for authorising and undertaking programmes and projects.
Programme Management Design Authority
- Updating, supporting and obtaining user feedback (including lessons learned) on the project environment and future developments.
- Developing and communicating changes to the environment.
- Ensuring that the staged project management framework and associated project controls are in place and used throughout the organisation.
- Preparing and leading briefings on the frameworks and their use.
- Ensuring there is a consistent and complete range of project management training and development programmes available.
- Ensuring consistent recruitment and selection tools and processes are available for project management related appointments.
- Ensuring that the project processes interface at a high level with other core processes within the organisation. Providing consulting, coaching and facilitation to users of the project framework.
DESIGNING ACCOUNTABILITIES
When designing accountabilities, make sure they are mutually compatible. You cannot design any accountability in isolation; it must always be designed in relation to the other accountabilities with which it interfaces. Never design an accountability which undermines another. For example, notice the Programme Management Director is not accountable for benefit realisation as that sits with the Business Programme Sponsors (see p. 170). In the accountability sets in this book I have taken the view that accountability for delivery and benefit realisation pass through the Project/Business Programme route, but that the methods they use are owned, for the total organisation, by the Programme Management Director.
Support offices – who supports whom on what?
This brings us to the subject of ‘project support offices’; what exactly should a ‘support office’ do to support programme and project management and how should this service be provided? Whilst many proprietary methods define a ‘support office’ role, you will find they often have different activities and styles associated with them. To make matters worse, many of them are not clear who they are supporting. As with many project management related topics, there is no single commonly agreed definition or approach; you have to create your own, drawing on whatever experience is available (including this book!).
I find the easiest way to approach this is to:
- assume a support office has no accountabilities of its own;
- decide which roles the office supports;
- look at which aspects of the supported roles can be undertaken by the support office.
You can then look at the discrete accountabilities associated with each supported role and decide which will benefit from a support service. This gives you a list of what the support office needs to do. Project Workout 17.2 provides you with a step-by-step approach. You may find the list is very short and focused. It may, however, be very wide ranging; if so, you should consider if a single office is the best way to provide the service. You may find it better to design a network of local support offices, each supporting different roles, but which in total provides the services you require.
How the offices undertake the support services very much depends on:
- whether the aspects of the roles supported are optional or mandatory;
- the overall culture of the organisation.
If the activities are optional, the support office will need to rely on ‘pull’ influencing styles in order to move forward. If the aspect being supported is mandated by policy, then assertion can be used (see p. 284 on influencing styles). If the organisation culture is very loose, allowing senior managers a high degree of freedom in how they carry out their accountabilities, the support office is unlikely to be accepted if it takes a very prescriptive approach. In which case, use your finance department as the tough guys!
Finally, you need to determine the staffing competencies and volume of work (throughput) the offices need to cope with, so that you can decide on the staffing levels. For instance, will a central office supply all services to everyone? Will it expect some services to be provided by ‘local’ offices, or expect some accountabilities to ‘serve themselves’ while using tools and methods which are centrally owned?
The key roles to be supported
In Chapter 14, I proposed a set of governance accountabilities for enterprise-wide programme management (see Figure 14.2). By adding project management and line management to these, we can draw up a process and accountability model for the entire organisation (Figure 17.1). Notice that I have also added the accountability for a Programme Management Director, which I introduced at the start of this section. Against each of these accountabilities you can list the types of support service which you feel should be provided in your organisation and the extent to which that service is supplied. By doing this, it soon becomes very obvious that the needs of the accountabilities are very distinct and hence the roles of the support offices different. For example, supporting a project manager in planning and risk management is totally different from supporting a Business Programme Manager on business planning.
Figure 17.1 The key roles which may require a support service
When deciding what support offices you need, think first of the roles which need to be supported. Then decide what aspects of the roles would benefit from a support service and the extent to which the service needs to be supplied. Look for combining offices where it makes sense, e.g. the Enterprise Programmes Office and Authorisation Support Office.
NAMING THE OFFICES
There is no set standard for naming the support offices. What the United States calls a ‘Project Office’, the UK calls ‘Project Support’, with ‘Project Support Office’ used for the corporate level office. In practice, you’ll find every conceivable combination of the words ‘programme’, ‘project’, ‘support’, ‘management’ and ‘organisation’. Where possible, name the offices after the entity, role or group it supports. Hence a ‘Project Support Office’ supports a ‘project’. ‘Projects Support Office’ supports a number of projects and ‘Business Programme Office’ supports a Business Programme. If an office supports a particular project, then name the office after that project, e.g. ‘Trident Project Support Office’. You will not believe how many phone calls I used to receive from ‘the project office’ with little clue as to which of about 40 were calling! You will of course have to fight your way through the ‘project’ versus ‘programme’ debate when choosing names (see below). You should then ensure each office has a role description comprising a few lines of summary and the individual activities bulleted. The summary can then be used liberally in communications, so there is little doubt as to what the office supports.
Support offices – some examples
The permutations for designing a support office infrastructure are limitless and can be very daunting. Project Workout 17.2 provides you with a process to follow in creating your own, but in order to bring this to life the following illustrates a snapshot of a typical support office set-up, which you can use as a basis for developing your own. Do note, however, that the service level provided by the offices very much relates to the maturity of the organisation in respect of programme and project management. As the organisation matures, the range of services that the office provides will increase. Its focus, however, will shift. In the early days much time will be spent on the basics of administration, project control and understanding the staged framework. Once this is established, such support will be available either from local offices or colleagues on a less formal basis. The offices will have swung to implementing or improving other aspects of capability. The proactive nature of support offices in continuously pushing corporate capability forward is essential to moving up the maturity ladder.
The Enterprise Programmes Office, or, as some people presumptuously call it, the ‘Centre of Excellence’ (I do dislike that term!), is the hub for all things related to programme and project management. It supports the Programme Management Director, ensuring the organisation has a complete programme and project environment commensurate with its level of maturity. It sets the ‘way we work’ for the organisation in relation to all programmes and projects by providing methods and systems; a key role in this respect is the Programme Management Design Authority. The office also provides an overview of the aggregated performance of the organisation with respect to programme and project management, with a specific focus on benefits realisation.
Other services offered by the office can include the following:
- Undertaking independent reviews and audits of projects.
- Developing, procuring and selecting project management support tools and systems.
- Consolidating programme and project reporting.
- Monitoring resource usage across the organisation.
- Providing consulting and coaching and advising project sponsors and managers in carrying out their roles. This can range from simple ‘response to phone calls’ to providing a full facilitation and consulting service on specialist topics such as project set up, risk management, issue management, planning and project closure.
- Maintaining standards for recruitment and development of project management staff (often working with the HR department).
- Providing Project Support Office services (see below).
- Providing trained project management staff for assignment to projects.
In some cases it is beneficial to combine this office with that of the Business Planning Office and Authorisation Support Office (see below) to create an extremely powerful grouping which not only provides methods but also helps those accountable drive strategy through delivery to benefits realisation.
The Business Planning Office supports the Business Strategy and Planning Board in the development, update and monitoring of the Business Plan. It has a strategic focus.
The Business Programme Offices each support the respective Business Programme Sponsor and Manager and are at the heart of driving the part of the business strategy and plan within their scope. Key to this is developing the Blueprints (description of future state) and Business Programme Plans and then executing them through initiating and running programmes/projects together with managing benefits realisation. Whilst they should use the approaches developed by the Enterprise Programmes Office, they may create tailored variants to suit the particular types of project and work they do. For example, the product development process is a special form of the project framework. They may also have their own variants for project approval.
Other services offered by such offices include the following:
- Checking documents prior to submission through the project authorisation process.
- Managing the flow of documents for authorisation, whether locally authorised or by higher authority.
- Providing a secretariat service for the Business Programme Sponsor/ Manager and communicating the outcomes and decisions.
- Undertaking independent reviews and audits of projects.
- Providing consolidated programme and project reporting within the Business Programme.
- Assisting in identifying and engaging stakeholders.
- Resource usage monitoring for programmes and projects within the Business Programme.
- Consulting, coaching and advising project sponsors and managers in carrying out their roles.
- Providing Project Support Office services (see below).
- Providing trained project management staff for assignment to projects.
If the business programme supports external projects (those for clients/customers), it may also include a sales and bid management capability.
The Authorisation Support Office supports the Project Review Group (see p. 188), ensuring flow of documentation to the correct decision makers (authorisation process) and providing a secretariat service for running decision-making meetings, communicating the outcomes, updating systems (e.g. releasing cost codes) and securely archiving the relevant documents. In addition, this office may provide a quality review service for the documentation which is submitted through the process, to ensure the decision makers have reasonable documents presented and to provide a commentary on aspects they should focus on or query. This role can be combined within the Enterprise Programmes Office.
The Project Support Office(s) supports project sponsors and, in particular, project managers in their accountabilities. This can range from ad hoc advice and guidance to providing a fully resourced service for tasks such as project planning, procurement or contract management, if not already provided by specialist central functions. The focus of these offices tends to be administrative support for the project manager. A number of models are used and the extent to which a service is provided may vary significantly, including:
- a single office providing services to a number of key projects;
- a single office providing a service to all projects, regardless of size;
- a number of offices each providing services to a number of key projects;
- a number of offices each providing a service to a portfolio of projects, regardless of size;
- each major project having its own project support office, staffed from centrally owned resources;
- each project organising its own arrangements for support.
Typical activities undertaken by the Project Support Office include the following:
- Administering Project Board meetings.
- Maintaining and operating the communications and stakeholder plans.
- Administering change control, risk logs, issues logs and action lists.
- Setting up and maintaining project files.
- Establishing and operating document control procedures.
- Maintaining plans (data collection and tools update for cost, schedule, scope and interdependencies).
- Administering the quality review process and standards.
- Reviewing key project documents (e.g. business cases).
- Administering document control and configuration management.
- Assisting with the compilation of reports.
- Administering contracted-in resources and facilities.
- Ensuring compliance and best use of corporate methods.
- Providing specialist knowledge, tools and techniques.
- Project assurance.
17.2 FIGHTING YOUR WAY THROUGH THE OFFICE FOG
This workout should be undertaken with the design authority and other key advocates of project and programme management. It should be carried out after you have established the key roles and accountabilities for your programme management framework. If these are not yet completed, use the roles and accountabilities provided in this book, but do remember to check back later to see if they are still valid for your organisation. If some support offices already exist, include the managers of them in your workout and determine where they sit with respect to the new roles and accountabilities. You should allow up to a day for this, not including the write-up and agreement after the workshop is completed.
- Using a paper-covered wall, construct a table which includes the roles and accountabilities in your framework. (There is a model to get you started on the CD-ROM.)
- Put a tick against each accountability/activity for which you believe support would be beneficial.
- Against each accountability requiring support, decide what the support may comprise. Use three levels of support (high, medium and low), describe on a Post-It Note what that means in practical terms. Place the notes on the wall chart. Select which level of support you feel should be provided by marking the relevant Post-It note with a different coloured note (you may change your mind later). In writing these, consider the style and mandate you want the offices to have. Use active verbs to describe the service, being as specific as possible, e.g. assist; advise; guide; review; recommend; provide; own; enforce; decide; instruct. Be specific about who owns, develops or uses a process/method.
- Name any existing support offices in the right-hand columns. For each existing support office, write on a Post-It Note what service it provides against the relevant accountabilities. If it provides a service for an unlisted accountability, add it to the bottom of the chart.
- Based on the support requirements and the existing provision (if any), decide on an initial guess for different support offices. Name these in the right-hand columns.
- Transfer the ‘desired support service’ Post-It from step 3 to the column for the support office which you think is best placed to provide the service.
- Take a break! Clear your head.
- As a group, run through the accountabilities of each office. Look for opportunities to consolidate services into fewer support offices.
- For each office decide its primary location, being the best location from which to provide the service. Some offices may be ‘virtual,’ with staff residing in different locations.
- Briefly outline the type of infrastructure the offices will need to operate. For example, shared intranets, document management systems and project support tools are usually essential for modern programme management.
- For each office define the type of people required to staff it. Purely administrative activities need lower-qualified staff than activities requiring specialist knowledge and skills.
- Based on your knowledge of the volume of projects and work involved, take a view on the numbers of people required. Decide if they all need to be full-time staff or if some roles (e.g. coaching) can be supplied by practising managers on a peer to peer basis.
You now have a detailed set of accountabilities for your offices, together with an outline of staffing, location and infrastructure needs. This is sufficient to include in a project plan for implementing your office structures.
The tools to help it work – systems
’The most useful thing I have is a list of what I’m meant to be working on,’ said a senior manager from an information systems function.
He was pointing out that, previously, the people in his function were asked to work on the systems parts of numerous projects spanning marketing information, financial, billing and customer service processes among many others. He had learned that it was impossible for his function, on its own, to prioritise this workload and decide what needed to be done and when. The outputs they produced were valueless unless they were combined with the other component parts of the project. By having an agreed ‘list’ of projects, he is now very clear which projects the organisation wants done and that no others should be worked on. In addition, the staged framework ensures that any particular part of the project does not proceed ahead of the others and that full checks on resource availability have been carried out.
The conclusion is that the key control tool to help you manage your project portfolio and ensure that work around the organisation is aligned is the publication and maintenance of a ‘list of projects’, sometimes called a ‘project register’.
What does the project ‘list’ look like?
Once people start talking about lists, the words ‘computers’, spreadsheets’ and ‘databases’ spring easily to mind. These are the tools that make managing the ‘list’ easier. All too often, however, these systems can be made too complicated and have a tendency to be taken over by the technical people who create them – they can be fun. You need to keep in perspective that they are only tools, which help the organisation achieve its objectives and so must be suited to the processes, systems and culture they serve. Reporting is a key part of the tools. It does not matter how good the data you put in are, if you can’t get useful information out, they prove an empty shell at best and totally misleading at worst. (You will find that if you can’t get the information out, people will not bother to put anything in, no matter how much you plague them!)
SYSTEMS AS REINFORCERS FOR CULTURAL SHIFT
Good systems can help support the drive to move culture in a particular direction. If, for example, you want to favour a projects environment where personal accountability is key, then having real people’s names attached to accountabilities can be powerful. This is especially so if the system that holds that data is easily accessible to those named people and to those who depend on them.
Systems needs
Your ‘list’ system needs to be designed such that users, with differing requirements, can access the same data to obtain the information they need, in a format which is convenient for them. They need to be able to:
- select the data they want to view;
- sort the data in an order that suits them;
- report in a format or template which serves their needs.
Information systems for keeping track of portfolios of projects generally centre around three sets of data:
- resources;
- non-financial data;
- financial data.
I dealt with resources in Chapter 16. The other two sets are dealt with in the following sections. Finance functions tend to have specialist accounting systems dealing with the ‘money matters’. These systems are not primarily designed for holding the non-financial data which you will find useful. Systems are available which can do both, but they are mostly in their infancy and not mature enough to deal with the wide range of ways people want to manage their businesses.
An investment approval process in a major organisation required that all the departmental managers impacted by the project had to sign the front sheet in ink. The result was a sheet with anything up to 25 signatures on it. Somewhere in that forest of names was a decision maker.
The new process still requires the impacted functions to review and commit to the project; however, no signatures are required. The only signatures are those of the decision makers:
- the project sponsor;
- the director of the department with overall project management accountability;
- the director with the budget which will fund the project.
It is quite clear who is accountable for the decision: the person who wants it, the person who does it and the person who pays for it.
‘No snowflake in an avalanche ever feels responsible.’
STANISLAV LEE
Lists – keeping tabs on your projects
If you are to keep track of your projects you will need to have a definitive list of the requests for new proposals and the projects currently in progress. The following should give you a feel for the basic requirements.
Capturing the new proposals
A proposal needs to be logged with a unique reference number from the moment a sponsor wishes to declare its existence. This MUST be prior to the Initial Investigation Gate. It may be as early as when a strategy or plan document is created and flags up the need for a potential project and hence earmarking of funds. A proposal document need not be created before a request is logged; however, sufficient information must be available to describe the objectives and benefits of the potential project.
A proposal is converted, via the Initial Investigation Gate, to a project as an initial investigation and on into the staged framework.
It should be possible to track back from any project that is in progress to find where the original request/proposal came from. In addition, if a request/proposal is converted to a project, it should be possible to see whether the project was in fact completed or terminated early. ‘Key word searches’ are useful to analyse the population of activities based on any of the header or other data for each proposal (e.g. rejected, terminated, etc.).
Projects list
There is a need for a central ‘database’ which can be used as an information system/reporting tool for individual projects and portfolios of projects. This system(s) should contain all projects being undertaken in the organisation. The database should provide information in support of gate decision makers, resource managers, business planners and project sponsors.
The requirements are for you to have:
- project header data (name, accountabilities, etc.);
- interdependencies with other projects;
- milestone data;
- cost data;
- progress information;
- useful and targeted reporting.
Project header data
The following data should be held for each project:
- project number, project name, business objectives, project framework stage, project sponsor, project manager, managing business area; this will be in the business case (see p. 294);
- which ‘Business Programme’ the project belongs to (if any);
- which programme the project is part of (if any);
- its status (proposed, in progress, on hold, terminated or completed);
- whether the project is ‘standard’, ‘simple’ or ‘emergency’, as defined in Part Two;
- the platforms, systems, processes and products impacted by the project;
- specific header data which are relevant to specific categories or type of project, e.g. project review group.
Project interdependencies
The project definition of each project includes its interdependencies. A dependency is defined as a deliverable produced by one project which is needed by another project in order to achieve its targeted benefits (see also pp. 299, 353). It is essential that this is known, defined and maintained. It must be possible to enquire:
- which project(s) depend on this project;
- which project(s) this project depends on.
A simple listing of projects and those which it depends on may be sufficient for your needs, but if the database is to be used as a decision support tool to enable portfolios of projects to be analysed and the business impacts seen, you may need to include more detail. This could comprise the planned and forecast dates for the transfer of each key dependent deliverable from one project to the other.
Milestone data
The system should hold milestone schedule data as original baseline (with date set), current baseline (with date set), achieved date (if completed) and forecast date (for uncompleted milestones) for the following:
- the gates in the staged framework (Detailed Investigation Gate, Development Gate, Trial Gate, Release Gate, Release, project completed);
- additional project manager-defined milestones in addition to those already stated.
Cost data
If project costs are held in a separate financial system, it is useful to import them into a central management information system to enable you to report on mixes of financial and non-financial information. The system should hold:
- actual costs to date for the project by project stage;
- forecast costs to completion by project stage;
- costs in two categories:
- manpower (time costs);
- external purchases.
See Figure 22.4 for an example.
Benefits forecasting data
The system should hold the ‘benefits’ forecast for each project both in ‘plan’ form (i.e. as per the authorised business case) and as a forecast (i.e. the estimated outcome at the current point in time). This may also be in the form of ‘conditions of satisfaction’ (see p. 332).
Progress information
The system should be able to be used as a corporate reporting repository, capable of producing a standard report (see p. 311) for each project, containing:
- key header data;
- business objectives;
- progress summary and outlook;
- financial summary;
- milestones;
- issues and risks;
- changes (via formal change management).
Reporting generally
The requirement is to provide a range of user roles with targeted, selected and sorted reports to meet their needs. Users will require either:
- detailed reports on individual projects, or
- summary reports for portfolios of projects as selected, sorted using any of the other data field criteria.
So users:
- select which projects they are interested in (based on the data stored in the information system;
- sort the data in the order they need (at least three levels of sort criteria);
- choose a report from a set of prescribed templates at a full, summary and/or analysis level. This can be either printed or exported to external applications.
The standard reports should be either:
- qualitative (i.e. non-numerical);
- or quantitative (cost-based, benefit based, timescale), with subtotals and totals.
Examples
- A project sponsor may select a portfolio report showing all the projects he/she is sponsoring.
- A director may select a portfolio report of all the projects being sponsored by him/herself and anyone else in the function.
- Or he/she may select a report of all the projects which will benefit his/her function.
- A line manager may select a portfolio report of all the projects which are being managed by his/her staff
ACTIVE AND PASSIVE REPORTING
You should always distinguish between active and passive reporting. If you want stakeholders to know something, you should tell them. You should not expect them to consult a database to find out if anything of interest has happened which is critical for them to know. Project databases are passive and you cannot assume that anyone will look at them.
Harnessing web technology
One of the biggest advances in project management over recent years is the provision of internet (or intranet)-based environments for displaying project and programme information. Everything we have talked about in the preceding sections has very much been for the benefit of those directing and managing portfolios of projects. Whilst essential for corporate management, to the project managers and teams who actually enter project data into databases (rather than use aggregated reports from the data bases) it is all too often seen as ‘non-value-added bureaucracy’. In many cases such tools duplicate the project manager’s own records and systems.
It is an obvious step to ‘web enable’ the project register. This has two advantages:
- roll out of the tools is simplified as the key interface is through the web browser (such as Internet Explorer or Firefox);
- the information can be made available to anyone who needs it. The more people who use it, the more likely those supplying the data are to keep it current.
The next step, however, is to turn the web environment into the actual tools the project manager and team can use on a day-to-day basis. For this to happen, a number of additional features are needed, such as document libraries, control logs, action lists and ‘talk zones’. In this way, the basic data collection for central reporting and tracking is drawn from the actual data the project managers are using and most of the drudge associated with central reporting systems is eliminated; it becomes a secondary effect of ‘doing the project properly’.
There are a number of criteria you need to consider if such web-enabled environments are to be effective:
- Someone must be accountable for the system and its features. These tools always attract a wonderful array of possible enhancements. Unless someone has a very good grasp of the architecture and how it fits the project methods in the organisation, destructive complexity and inconsistencies will soon be introduced.
- Someone has to be accountable for the data quality of portfolios of projects. Every project manager should be accountable for his or her own data but above that level, someone needs to check (say, at Business Programme level) overall integrity. The introduction of a ‘quality score’ is a good method for assessing this. The score should be designed to tell users of the data the extent to which they can ‘trust’ the project and portfolio reports which are generated.
- Anyone who needs access should be given access. If half the team are ‘locked out’ behind a firewall, any information they need will have to be duplicated elsewhere. It truly needs to be an enterprise-wide system and may often need to include suppliers and contractors;
- Manually duplicating data which is held in other systems should be avoided. If it can be imported or drawn on directly, then do so. Systems based on open architectures are particularly good for this.
- User response time has to be acceptable. If adding data or drawing off reports takes too long, people will not use it.
What would such a system look like?
There are an increasing number of web-based project and knowledge management environment systems on the market. They enable you to direct, manage and coordinate project teams and information, regardless of where they are based or which organisations people belong to.
Features, complexity and reporting
When deciding the features for your project management environment, you will find that the options are endless. The more features you have, the more complexity is likely to result, with all the difficulties that entails. Look for systems which are built on a core of base features, each of which enables a high degree of user configuration at both corporate (portfolio and programme) and project levels and each of which has an obvious use in real life. There may be some features you do not want yet (or at all); see if you can ‘disable’ these so they won’t clog your screens with ‘useless’ clutter. Again this should be at both corporate and project level. Many software suppliers make their profit from ‘customising’ their offerings. On the face of it, this can look very customer-focused, but it can also be a very expensive and not necessarily fruitful pathway. The design of all systems is based on an assumed operating model. If your customisation conflicts with this model (for example, you have a totally different view on how to allocate access permissions), the impacts can be very unpredictable. However, one area that I feel customisation should be given free rein in is reporting. Systems are useless if they do not convert data into meaningful information through screen-based, printed and exported reports. Designing new reports and creating better ways to present information is non-intrusive to the system architecture but adds value for the user.
Apart from the usual project management features you may find the following capabilities useful:
- Organisation – the ability to assign roles and put people in teams (such as user groups, decision-making bodies).
- News – on-line newspaper to keep your team and wider stakeholder community up to date without boring them with the standard progress report!
- Communications – integrated e-mail, so the e-mails are stored with the project rather than on a corporate e-mail server ‘somewhere’, which no one can get at.
- Meetings – agenda, minutes linked to actions.
- Notifications – the system tells you when something you want to keep an eye on changes.
- Talk – on-line threaded discussions – great for capturing lessons learned and quality reviews.
- Timesheets – if you need to track time and there is no corporate system.
- Search and report – essential if a system is to be of any use. If you can’t find something, it’s useless!
An example of a system
For illustration, I will use e:PSO, one of the many tools currently on the market, but you should look for similar capabilities on whatever system you select. The e:PSO is based on the best practices and principles found in this book, but can be adapted to fit virtually any method.
The system recognises who you are through your ‘login’ details, which are entered on the main screen. From here, you are taken to your ‘My Home Portal’, which contains links to all elements of the system relating to you (including existing projects, outstanding issues, actions, etc.). (Figure 17.2). By using the menu options along the top of the screen you can move to different areas of the system; for example, you can view a flow chart of all projects within the system. This flow chart divides the projects between different stages of the project life cycle. Clicking on a stage will bring up a list of all projects currently at that stage, together with a high-level view of some of the details, such as location, cost and priority (Figure 17.3). Some of the details only show at certain levels – in the example, showing projects in the different life cycle stages, the overall status of the project is also shown. Each project included on the list also has a set of ‘Quick Links’, which enable you to move to more detailed screens, such as milestones, risks and product/tasks.
Figure 17.2 Keeping track of your accountabilities!
The power of systems is that you can find what you need quickly. In this case, I can see an overview of every item I am accountable for.
Figure 17.3 A typical project listing
This screen displays a list of projects satisfying the user’s search criteria (in this case the life cycle stage). From this we can see some of the key ‘headline’ project data. We can also ‘drill down’ for more detail.
Selecting any one of the projects takes you into that project’s ‘Detail View’ (Figure 17.4). This screen provides a high-level description of the project, together with a summary of the key data. From here you can then access all the detailed information about the project using the ‘Quick Links’ at the top of the screen.
This approach enables the project sponsor, project manager and team to keep track of risks, issues, milestones and many other aspects of the project. The example in Figure 17.5 shows a listing of the risks relating to a specific project. Selecting the ‘Open Record’ option enables you to see more detail about the specified risk.
For a demonstration of this tool, go to www.live.projectworkout.com.
Figure 17.4 A project’s ‘Detail View’
Each project has a ‘Details View’ from which all the key information relating to the project can be found. The front page shows an overview of each area of the project and the links found at the top of the page can be used to navigate to even more detailed views.
Figure 17.5 One of the control tools – the risk log
Specific information on a project can be accessed using the links at the top of each project’s ‘Details View’. In this case, the risk log is shown. You can view more details by selecting the ‘Open Record’ button next to your chosen risk.
RAG STATUS
If using critical chain project scheduling (see p. 373), the RAG status would indicate the degree to which the project buffer had been used.
Management accounting systems
The missing dimension
‘What we do is more important than where we sit in the organisation.’ This may be what we feel but it is not what many of our management accounting systems measure or report. Currently many organisations count money in only two dimensions:
- a cost centre code (against whose budget money is spent);
- an analysis code (what it is spent on).
They do not say how the money is applied, i.e. what is actually done with it.
Sometimes they try to do this in part by using a cost centre code or an analysis code to capture the essence of where money is applied. For example, a cost centre is opened to capture costs for a particular project. While this may be pragmatic, it does not serve the full management accounting needs of the organisation of the future.
A third dimension of accounting is needed to cover the use to which our funds are put, regardless of what they are spent on and which cost centres resource them. I call it an ‘application code’.
In essence, this is a ‘source and application of internal funds’, which is useful at a grass roots management level as well as at senior management level.
So the three dimensions are:
- cost centre code – where money/resources come from;
- analysis code – what it is spent on;
- application code – why it is being spent.
The sum of each will always equal the same number as they are just different ways of looking at the money used in the organisation. It is essential this balance is made or we will encourage ‘leakage’ of funds or ‘cheating’.
The application code
What does an ‘application code’ look like? There should be three mutually exclusive application code types:
- P type – this is about creating change; taking us from what we do now to what we do tomorrow, i.e. projects.
- A type – this is doing ‘business as usual’ processes. In the steady state, e.g. retaining and acquiring customers, doing management tasks (business processes).
- X type – this is down time such as sickness, leave, training.
Typically, the X type is about 20 per cent of total ‘people’ expenditure. Who really knows, however, how much we spend on running our existing business (A type) as opposed to changing it (P type)? Do we even have a feel for what this should be?
A P, A and X type of management accounting system would give us the knowledge to sharpen our focus and ensure that we only do those things which are important to our meeting our strategic objectives, rather than merely keeping track of who spends the money.
Consider the picture of the business when using the traditional cost centre code approach:
We know the costs in each cost centre (the shaded part) (cost centre 1 = 20, cost centre 2 = 30, etc.), but we have no idea how the money and people are applied. This is revealed when the third dimension is added, giving us a richer picture of our business:
For the first time we will be able to run our organisations based on ‘what counts,’ i.e. where we apply our efforts rather than ‘what we can count’, i.e. the cost centre.
In this environment, cost centres will become ‘homes’ where ‘pay and rations’ are sourced and experience and expertise fostered. Many cost centres will be focused on particular activities but that is not a prerequisite. The application code will say what they are doing:
- away on paid leave?
- being trained?
- performing as part of the ‘business as usual’ task?
- working on a project?
By introducing the third dimension on all of our costs (people included), we will know what we are applying ourselves to.
The advantage of this is that the balance of power will move away from cost centres as the ‘fund-holding barons’ of the old hierarchical organisation toward the flat structured ‘what we do is important’ new corporation. AND … our key management tool (the management accounting system) will support this.
Management by accountability will thrive, as accountabilities will be tied to application codes which operate across the whole organisation, regardless of the cost centre to which the person holding the accountability belongs. In this way, any person can sponsor or work on any project or activity anywhere in the organisation without you losing control of the finances or the head count. For example, Figure 17.6 shows a typical financial report for a project sponsor. It shows the person is sponsoring five projects, one of which is terminated, one on hold and three in progress. This person is accountable for over $1m spend across the organisation.
As the three dimensions must balance, there is little scope or benefit for ‘cheating’. If a project is running over budget, there is no point in hiding its cost within another project or activity even if the owner would accept it! It would merely rob Peter to pay Paul and different performance indicators would move in opposite directions accordingly.
It would stop the racket of ‘head count’. It would no longer matter how many people you had in a cost centre as you would be concentrating more on what they did. There need be no pushing people out of the ‘home’ cost centre to do a ‘project’ only to fill their position with another (net effect equals one more head).
This may sound a radical approach, but it is within the capability of many organisations. It would require ‘time sheeting for all’, but we all do it now (e.g. we all fill in sickness notes, paid leave forms, etc.). In addition, as the bulk of employees only do one A type application and some X types, time sheets could be generated by default with only the exceptions requiring input. This would give you the freedom to deploy anyone anywhere, not ‘lose them’, and know what their input is being applied to. Thus ‘doing projects’ will stop being dangerous; no longer will they be the fast track to redundancy!
Further, we are in a rapidly moving business world. By adopting the management approach given here, reorganisations will become less important and can be done at any time in the financial year. P, A and X will be the way we will run our businesses!
The requirements for such a system, incorporating project costing, would be that each application code should:
- have a unique reference number;
- have costs captured against a work breakdown structure, representing, as a minimum, the stages of the project framework;
- have forecasts set;
- be viewed with or without absorbed overheads;
- have the staged authorisation of funds;
- have three status for transaction postings:
- open for forecast only;
- open for cost and forecast;
- closed.
Reporting should be flexible to reflect the life of a project, the current financial year and the future, enabling interest groups (such as project sponsors) to see their own projects as a portfolio.
Figure 17.6 is an example, showing the costs associated with Phillipa Brixham’s sponsorship portfolio. If your management accounting system is linked to your project database, these data could also appear at the foot of the report shown in Figure 17.4. Similar reports should be produced, selecting and sorting from any of the data which are held in the accounting system, with the ability to summarise at any level of the project work breakdown structure.
BOOKKEEPING!
You should distinguish between the management of costs from a management accounting perspective and from a financial perspective. The latter relates to ‘bookkeeping’ and where the transactions appear in the formal chart of accounts. In the management of projects, this is of little or no use. Managing the actual spend and cash flow provides far greater control.
Figure 17.6 Typical financial summary
This report shows the financial summary of Phillipa Brixham’s sponsorship portfolio. This report shows that she is accountable for $1.15m authorised spend on five projects, one of which has been terminated and another put on hold. Only one of her projects, 828, is forecast to overspend.
Putting your systems together
In the previous sections, we looked at the three primary information needs (resources, non-financial and financial) and have seen how they could be handled in our information systems. We have also seen how resource management relates to project cost forecasting and how this in turn builds into the business plan. Each system is targeted at a particular need; however, they are all related. Figure 17.7 shows the relationship in diagrammatic form. Actual expenditure on your projects is captured by the accounting system (the shaded boxes). These costs can be handled on both a project-focused basis and on a more traditional, cost centre basis. Forecast of manpower (person hours) is costed and then combined with the forecast of purchases to produce an overall cost forecast for the projects.
At the point marked ‘A’ the manpower forecasts are taken off and collated to give an early view of resource needs for line managers and the organisation as a whole. Once the actual costs and forecast costs have been collected they can be combined to produce the project financial accounts and summary reports. They can also be fed into the project database and combined with other, non-financial data, to produce an overall reporting capability. Where you keep your data, and how the reports are produced, will depend very much on the systems you have in your organisation. Regardless of this, however, the overall logic and flow should be very similar to that examined here. It won’t be easy to put in place, but if you have a vision of the future of your enterprise system’s strategy, you will gradually be able to build the full set. You will also find that having simple, separate systems may be the most pragmatic way forward, even if it means some temporary duplication of data and the risks that entails. It is better than not having a view of your project portfolio at all.
Web technologies are ideally suited to providing quick, simple and effective reports from disparate systems. They also have the advantage that user training is minimal. Web technologies can also be used for data capture.
Figure 17.7 The complete system
The links between resources, costs, benefits and other project systems. The outputs include both project reporting and the necessary inputs required for business planning (see also Figure 14.3).
17.3 YOUR OWN SYSTEMS
- Make an enlarged copy of Figure 17.7. Mark it up with highlighter pens, indicating the elements you currently have in place (shade in yellow) and those parts which you already plan to put in place (shade in another colour).
- Are the elements you have shaded designed to be compatible with each other?
- On a flip chart:
- list elements which are missing;
- list the data which would be contained within these elements;
- list the information you are lacking as a result.
- Consider, based on what you have in place, what actions you could take to fill any gaps you have identified in the systems environment supporting your projects framework.
