Agile project management and different project plans in Conventional projects are two hot topics.
Conventional phased projects are sometimes seen as having excessively time-consuming lines of communications. For example, users of a new system could be consulted at the requirements phase, but then have to wait a considerable time while the system is designed, built and tested. It is often only then that discrepancies in understanding of the requirements are detected.
A response to the perceived limitations of the waterfall project management approach has been demand for the adoption of what are called Agile practices. These tend to be practices that reduce bureaucratic obstacles by encouraging intense, informal communication between project participants. Some of these work at the level of individual work teams. Scrum, for example, breaks a project into a number of increments (see Section 1.7.2) of about two-week duration called sprints.
Within sprints, individual activities are broken into a series of small steps that are listed in a backlog. Each day the project team members report on their progress in implementing the items in the backlog in short ‘stand-up’ meetings.
Extreme Programming (XP)
Other Agile approaches – such as Extreme Programming (XP) – focus on software development practices. XP, for example, calls for software developers to work together in pairs, so the coding decisions of one developer are always checked by the other as the code is entered at a workstation.
These strategies are only applicable to some types of projects. They may be useful in software development, as code is relatively easy to change, but not in large infrastructure projects – although this may be changing with the development of computer-aided design.
Agile project management practices provide communication between stakeholders
Agile practices focus on creating real-time communication between project stakeholders. Thus, a knowledgeable product owner may be designated who acts as the sole authority on user requirements, thus avoiding lengthy requirements gathering. User representatives may work directly with developers creating ‘user stories’ precisely mapped to delivered units of functionality, and at the same time design the test cases and expected results that will be used to validate them. As noted above, developers may work in pairs so that there is instant checking on work as it is executed.
This sensitivity to the exact needs of users leads to greater user satisfaction, but at the cost of demands on the time of users. Local satisfaction is sometimes balanced by overall reduction in organisational efficiency with increased costs for the maintenance of a variety of non-standard products carrying out similar functions.A challenge comes when projects have to integrate activities that relate to different professional disciplines. Agile practices are likely to be applicable to only a small subset of these activities. A common overall project management system is needed to coordinate the efforts of a mixture of activities, some of which are Agile and some of which are conventionally organised.
The Agile emphasis on fixed time and cost constraints helps this. Regardless of the type of work, content managers of work packages need to be able to supply basic progress data to project management. Where Agile practices are involved, this may be easier to supply because work is more visible.We will be returning to other relevant Agile practices in later chapters, particularly Chapter 5, which discusses quality issues.
Project Plans in Conventional project management practices
The effective management of a project is based on a firm definition of project governance; that is, the principles, policies and frameworks by which a project is directed and managed. Among other things, this will set out who is accountable and responsible for each component of the project. Accountability refers to the management role which controls and reports on a particular activity within the project.
The accountable person might well not be carrying out the work. Someone else who reports to the accountable person could have responsibility for the practical work. If there were external factors preventing work being completed as required, the responsible team member would need to consult the person accountable for the work.
The Manager and the Software
Thus, a manager might be made accountable for delivered software being correct. One way of ensuring correctness is by testing and the manager could allocate a system tester to have the responsibility of carrying out this task. If the tester finds that, for example, the testing is being delayed because of late changes to the functionality, they would need to refer to the manager for guidance.
At the start of the project it might not be possible for all the accountable and responsible people to be personally named. Instead roles would be defined and then be allocated to actual people later in the project.
During the project set-up phase (see Section 1.4.3), a project plan is produced that consists of several different types of document, including activity networks and Gantt charts (see Chapter 2). It is used as the basis for the final decision by an organisation’s management to go ahead with the project, and as such is sometimes referred to as project initiation documentation (PID).
The PID is a set of documents that coordinate all project processes, bringing together all the planning documents used to manage and control the project. It is not cast in stone and will be amended as necessary during the lifetime (life cycle) of the project. The plan defines the project’s scope, schedule and cost, as well as the supporting processes related to risk, procurement, human resources, communication and quality.
Project initiation documentation (PID)
Different project management methods give this document different names, but in essence it serves as an agreement between the sponsors and the developers of the project. It has the following key elements:
- An introduction, which describes:
- the project background;
- the document’s purpose;
- the business justification for the project, including a brief summary of costs and benefits (see Section 1.9).
- Project goals, objectives and deliverables, including:
- project success and completion criteria;
- an outline of the technical strategy by which the goals will be achieved.
Project management plan explained
The following sections constitute the project management plan and explain how the project will be managed:
A project organisation chart, which includes:
- the project sponsor;
- the project manager;
- major stakeholder representatives;
- the lead supplier representative(s), if appropriate.
The organisation chart shows the reporting relationships of all those with managerial responsibility for aspects of the project. It also identifies the members of any steering committee (or project board or project management board) established for the project.
Chapter 8 discusses some of the issues involved in project organisation.
- A management control section, which covers:
- the frequency, timing, recipients and format of progress reports;
- how the plan will be produced and maintained;
- what information will be monitored and recorded;
- how the information will be recorded;
- how packages of work will be signed off and reviews conducted, and who is authorised to sign off packages of work;
- the people accountable/responsible for authorising the commitment of resources;
- the people accountable/responsible for recording and assessing the impact of any changes;
- the people accountable/responsible for authorising different levels of change to goals, objectives, deliverables, costs or completion date (change management practices).
Chapter 3 is devoted to monitoring and control. The following constitute the initial project plan, which describes the activities to be undertaken to complete the project:
A project structure section that describes how the project will be broken down into manageable portions of work, which will be administered as stages/phases.
A list of project milestones, that is significant events in the project for which dates need to be clearly specified. Milestones are used to measure the progress of a project and can be the start or completion of a major project phase. Milestones are events that consume no resources in themselves, but enjoy a great deal of attention from management at a senior level.
Management resources representing the project sponsors will be needed to review the state of the project before or after the milestone has been reached.
All risks and assumptions section identifying high-level risks to the project and specific actions to reduce or eliminate each risk. It is useful to include in this section a list of assumptions made in producing the report.See Chapter 7 for more on risk and its management.
A communication plan that provides an overview of how the project will communicate with the wider business organisation, particularly with regard to changes needed in the business in order to make the implemented IT application effective. See Chapter 8 for more on project communication.
A report sign-off section. The document should be signed off by staff who represent all areas and functions committing resources to the project and those who will be affected by the project. In so doing, they implicitly accept the assumptions listed. Final sign-off is given by the project sponsor. The project manager should not initiate any work that has not been explicitly or implicitly authorised in the project initiation document and signed off by the project sponsor.1.8.2
Creating project plans
The PID will contain an outline plan for the whole project and a more detailed one for the first stage. The detailed planning of later stages usually takes place closer to the beginning of those stages. This allows it to take account of the additional information gained during the progress of the project. Thus, plans are created at several levels:
Projects, where the outline plan is approved by the project sponsor, supported by any steering group/project board. Stages, where the completion of any previous stage is signed off and the stage plan for the next stage is approved by the project sponsor.
Work packages, which are the practical sets of activities that the project manager allocates to individuals or groups of developers under the guidance of a team leader or manager, who produces a detailed plan of how the work will be done. The plan starts with a careful breakdown of the work to be done.
The activities needed to carry out this work are identified plus the order in which they have to be carried out. An estimate of the duration of each activity is needed. Chapter 2 describes the use of Gantt charts for showing the schedule for a project.
The project plan needs to be developed further
The project plan then needs to be developed further to account for the various types of resources, including people, equipment and facilities needed for the activities identified. With internally resourced IT/business change projects, resources must be obtained from other parts of the company to work on a project.
Managers of specialist departments will be key providers of resources such as office space, computer equipment and specialist expertise. Where goods or services from outside the organisation are needed, contract management will be important.
Resource planning identifies the skills needed for the project and when they are needed; for example, a testing expert may only be needed at certain times in the project. Availability of resources often affects the timing of activities. A useful communication tool for the project manager is the responsibility assignment matrix (RAM), a simple matrix showing individuals associated with the project on one axis and the activities for which they are responsible on the other. It provides a quick and easy view of who is responsible for each task.
Once the activities and resources have been identified, the costs are assessed. The business case for a project is based on it not costing more than a specific amount reckoned to be the value of project benefits. If the costs of the project exceed the value of its benefits, the project becomes uneconomic. It is also possible for an organisation to simply run out of money for a project.
Internal IT projects
Internal IT projects are usually paid for out of a user department’s budget. Where a project is being carried out for an external customer, there may be a fixed-price contract. Whatever the case, it is necessary to estimate quantities and costs, set budgets and eventually control expenditure.
Sources of the development staff
A major IT project often requires an abnormal amount of technical work that the business cannot provide by itself. Additional development skills might be acquired by:
Recruiting individual specialists on temporary contracts, either directly or by using agencies. Pay for temporary staff is usually greater than that for permanent staff and there may be additional recruitment and training costs. Depending on the type of work, temporary staff could work from their own premises, but usually need workstations within the business.
In the case above, the temporary staff are employed directly by the business. An alternative approach is to have a contract with an outside specialist company where the developers used are based and remain the employees of the specialist company. The specialist company is paid for the hours that their employees work.
A more radical approach is to outsource one or more project activities, such as design and construction, to an outside specialist company. The outside company will have management responsibility for delivery of a subset of the project requirements, often for a fixed price. In this case, the supplier selection and the acceptance testing of deliverables would still consume some of the customer’s resources.