FE ENERGY

Project Management Phases and Processes

Structuring your project
MA - BDA

12

Project Phases
Phases, or stages, are very important for project managers. By thinking in terms of phases, you can ensure that the deliverables produced at the end of each phase meet their purpose, and that project team members (or sub-teams) are properly prepared for the next phase. You identify the required deliverables for each phase from the Work Breakdown Structure (WBS) for it. The WBS is drafted as part of your preparation activities, and then validated by the rest of the project team. At the end of each phase, someone signs off on the deliverables from that phase. (In your preparation phase, think through who needs to approve each deliverable. Approvers may include the project board, project sponsor, or key stakeholders.) Once the deliverables are approved, the phase is completed and the project team can pass through the "gate" to the next phase. This is why the term "stage/gate" is used so often in project management. The exact phases, and the order in which they're completed, may vary slightly, depending on what you need to achieve with your project. The phases are as follows:

1- Project strategy and business case

In this phase, you define the overall project business requirement (check appendix 1), and propose the approach or methodology that you want to use to address it. The gate at the end of this phase is the approval of your high-level project proposal and of the business case that validates the approach you want to use. You must also show that you can achieve the project's goal within the required timelines and budget.

Tip: Make sure that you review the business case at the end of each project phase to ensure that its still valid. If anything has changed, revise it as needed.

Done by: MA BDA

2- Preparation
Here, you work with key stakeholders and project team members who have already been identified to establish and start the project: 1. Complete a high-level Work Breakdown Structure (Check Appendix 2). 2. Determine the project's high-level plan at the milestone level (Check Appendix 3). (Work with appropriate project team members to produce detailed plans at each subsequent phase. This ensures that they have a sense of ownership of these plans.) 3. Identify and recruit project members. 4. Produce the Project Initiation Document (check Appendix 4). 5. Select third parties to use in the early project phases (for example, IT subcontractors or partners). 6. Put actions in place to secure key resources. (For example, reserve rooms for the training phase, and allocate desks and PCs/printers for the project team.) 3- Design Start the work involved with creating the project's deliverables, using the project strategy, business case, and Project Initiation Document as your starting point. Then work with relevant stakeholders to develop the designs of the main deliverables. In larger projects, you may use business analysts to help you with this. You probably have a project board or project sponsor who is responsible for signing off the overall design, but make sure you also get input from other stakeholders as well. This helps build business ownership of the project deliverables. If changes to processes are required, use a Flow Chart (check appendix 5) or Swim Lane Diagram (check appendix5) to create a detailed map of how things will work. At this stage, you must do everything you can to think through and deal with project issues before you start to build project deliverables problems are almost always easier and cheaper to fix at design stage than they are once the detailed work of implementation has started. Select stakeholders (check appendix 6) carefully for the detailed design phase. A good detailed design is more likely to lead to a good project deliverable. If the detailed design is poor, the project deliverables are much less likely to meet requirements! Tip: For projects that have significant technical risks and uncertainties, consider including a feasibility or proof-of-concept phase. This increases your certainty that what you're planning (probably at great expense) will work, while allowing you to cancel the project at minimum cost if the proof-of-concept fails

Done by: MA BDA

4 4- Development and testing With all of the planning and designing complete, the project team can now start to develop and build the components of the project output whether it's a piece of software, a bridge, or a business process. As part of this phase, you need to test these components thoroughly to confirm that they work as they should.

5- Training and business readiness

This stage is all about preparing for the project launch or "go live." Do the following things during this phase: a. Train users. b. Put in place ongoing support. c. Transfer data to new systems. d. Identify what's required for the project to be effective from the launch date, and ensure that you adequately address this. 6- Support and benefits realization Make sure you provide transitional support to the business after the project is launched, and consider what's required before your team members are reassigned. Project teams are often assigned to other work too soon after the project has gone "live", meaning that project benefits are often not fully realized. Monitor the delivery of project benefits (check appendix 7). You can use this to promote your project or to give you information about other actions needed to ensure that the project is successful. You can monitor benefits as part of "business as usual" activities, and you should (ideally) continue to do so after the project is closed.

7- Project close
Closing a project is not the most exciting part of the project lifecycle, but, if you don't do it properly, you may obstruct the ongoing delivery of benefits to the organization. Make sure you do the following: a. Complete and store documentation. b. Carry out a Post-Implementation Review (check appendix 8), so that you and your colleagues can use the experience you've gained in future projects.

Done by: MA BDA

5 c. Use your business connections to reassign project team members to appropriate roles in the organization. You don't want to lose the experience and knowledge that they've gained from working on the project

Project Management Processes

The key project management processes, which run though all of these phases, are: Phase management.

Planning. Control. Team management. Communication. Procurement. Integration.

Let's look at each process in more detail.

Phase management

Here, you ensure that you adequately satisfy the conditions for completing each phase, and for starting the next one. To do this, make sure that you fully understand the "gates", or deliverables that must be completed and approved by the appropriate stakeholders before you can exit a phase. Deliverables and sign-off requirements are usually identified in the Project Initiation Document (check appendix 4), so review this appropriately during the project.

Planning

Carry out high-level planning for the whole project at the start of the project, then do more detailed planning for each phase at the start of each phase. Ensure that you have the right people, resources, methodologies, and supporting tools in place for each planning phase, so that you can deliver the project on time, on budget, and to appropriate quality standards.

Control

It's essential to control scope, cost, and issues; and to manage time, risks, and benefits effectively. Create reports that contain the information you need to create an accurate picture of how things are proceeding. A common way of doing this is to use a Project Dashboard (check appendix 9).

Done by: MA BDA

Team management

As project manager, you are responsible for managing the project team. Working on a project is often different from most "business as usual" activities, and project work may require a different approach and set of skills. As such, you'll probably need specific project management training and support. And there are additional complexities in managing team members who have project responsibilities as well as other roles at the same time (check appendix 13 for Managing Cross-Functional Teams)

Communication

Make sure that you're clear about who is responsible for communicating to team members, the project board, the different stakeholders within the business, and relevant third parties. Inadequate communication is a frequent problem area for projects, and it needs considerable attention to communicate well.

Procurement

This is a specialist area. Many projects hire third parties to manage purchasing, particularly when it involves IT systems. Managing these third parties is often the role of the project manager. 8- Integration Many projects do not stand on their own within an organization they often impact other areas of the business. Make sure that you consider how your project will interface with other projects or functions.

Done by: MA BDA

Appendix 1: Business Requirements Analysis Clearly Agreeing What You're Going to Deliver
Every new activity, every new product, every new project in the workplace is created in response to a business need. Yet we often find ourselves in situations where, despite spending tremendous time and resources, there's a mismatch between what has been designed and what is actually needed. Has a client ever complained that what you delivered isn't what she ordered? Has someone changed his mind altogether about the deliverable, when you were halfway through a project? Have you had conflicting requirements from multiple clients? And have you ever received new requirements just after you thought you'd finished creating a product? A focused and detailed business requirements analysis can help you avoid problems like these. This is the process of discovering, analyzing, defining, and documenting the requirements that are related to a specific business objective. And it's the process by which you clearly and precisely define the scope of the project, so that you can assess the timescales and resources needed to complete it. Remember: to get what you want, you need to accurately define it and a good business requirements analysis helps you achieve this objective. It leads you to better understand the business needs, and helps you break them down into detailed, specific requirements that everyone agrees on. What's more, it's usually much quicker and cheaper to fix a problem or misunderstanding at the analysis stage than it is when the "finished product" is delivered. Tip: Many organizations already have established procedures and methodologies for conducting business requirements analyses, which may have been optimized specifically for that organization or industry. If these exist, use them! However, do make sure you also consider the points below. How to Use the Tool Below is a five-step guide to conducting your own business requirements analysis.

Step 1: Identify Key Stakeholders

Identify the key people who will be affected by the project. Start by clarifying exactly who the project's sponsor is. This may be an internal or external client. Either way, it is essential that you know who has the final say on what will be included in the project's scope, and what won't.Then, identify who will use the solution, product, or service. These are your end-users. Your project is intended to meet their needs, so you must consider their inputs.

Done by: MA BDA

Tip: Make sure that your list is complete: remember, end-users for a product or service might all be in one division or department, or they might be spread across various departments or levels of your organization. Our article on Stakeholder Analysis will help you identify stakeholders.

Step 2: Capture Stakeholder Requirements

Ask each of these key stakeholders, or groups of stakeholders, for their requirements from the new product or service. What do they want and expect from this project? Tip 1: Remember, each person considers the project from his or her individual perspective. You must understand these different perspectives and gather the different requirements to build a complete picture of what the project should achieve. Tip 2: When interviewing stakeholders, be clear about what the basic scope of the project is, and keep your discussions within this. Otherwise, end-users may be tempted to describe all sorts of functionality that your project was never designed to provide. If users have articulated these desires in detail, they may be disappointed when they are not included in the final specification. You can use several methods to understand and capture these requirements. Here, we give you four techniques: Technique 1: Using stakeholder interviews Talk with each stakeholder or end-user individually. This allows you to understand each person's specific views and needs. Technique 2: Using joint interviews or focus groups Conduct group workshops. This helps you understand how information flows between different divisions or departments, and ensure that hand-overs will be managed smoothly. Tip: When using these two methods, it's a good idea to keep asking "Why?" for each requirement. This may help you eliminate unwanted or unnecessary requirements, so you can develop a list of the most critical issues.

Done by: MA BDA

9 Technique 3: Using "use cases" This scenario-based technique lets you walk through the whole system or process, step by step, as a user. It helps you understand how the system or service would work. This is a very good technique for gathering functional requirements, but you may need multiple "use cases" to understand the functionality of the whole system.

Tip: You might want to find existing use cases for similar types of systems or services. You can use these as a starting point for developing your own use case. Technique 4: Building Prototypes Build a mock-up or model of the system or product to give users an idea of what the final product will look like. Using this, users can address feasibility issues, and they can help identify any inconsistencies and problems. You can use one or more of the above techniques to gather all of the requirements. For example, when you have a complete list of requirements after your interviews, you can then build a prototype of the system or product.

Step 3: Categorize Requirements

To make analysis easier, consider grouping the requirements into these four categories: Functional Requirements These define how a product/service/solution should function from the end-user's perspective. They describe the features and functions with which the end-user will interact directly. Operational Requirements These define operations that must be carried out in the background to keep the product or process functioning over a period of time. Technical Requirements These define the technical issues that must be considered to successfully implement the process or create the product. Transitional Requirements These are the steps needed to implement the new product or process smoothly.

Step 4: Interpret and Record Requirements

Once you have gathered and categorized all of the requirements, determine which requirements are achievable, and how the system or product can deliver them. To interpret the requirements, do the following: Define requirements precisely Ensure that the requirements are:

Not ambiguous or vague. Clearly worded. Sufficiently detailed so that everything is known. (Project over-runs and problems usually come from unknowns that were not identified, or sufficiently well-analyzed.)

Done by: MA BDA

10 Related to the business needs. Listed in sufficient detail to create a working system or product design. Prioritize requirements Although many requirements are important, some are more important than others, and budgets are usually limited. Therefore, identify which requirements are the most critical, and which are "nice-to-haves". Analyze the impact of change carry out an Impact Analysis to make sure that you understand fully the consequences your project will have for existing processes, products and people. Resolve conflicting issues Sit down with the key stakeholders and resolve any conflicting requirements issues. You may find Scenario Analysis helpful in doing this, as it will allow all those involved to explore how the proposed project would work in different possible "futures". Analyze feasibility Determine how reliable and easy-to-use the new product or system will be. A detailed analysis can help identify any major problems.

Once everything is analyzed, present your key results and a detailed report of the business needs. This should be a written document. Circulate this document among the key stakeholders, end-users, and development teams, with a realistic deadline for feedback. This can help resolve any remaining stakeholder conflicts, and can form part of a "contract" or agreement between you and the stakeholders. Step 5: Sign Off Finally, make sure you get the signed agreement of key stakeholders, or representatives of key stakeholder groups, saying that the requirements as presented precisely reflect their needs. This formal commitment will play an important part in ensuring that the project does not suffer from "scope creep" later on. Key Points The key to a successful business requirements analysis is identifying what the new system or product will do for all appropriate end-users/stakeholders and to understand what they WANT the new system or product to do. You can use various techniques to gather requirements, but make sure those requirements are clear, concise, and related to the business. This process also helps you identify and resolve any conflicting requirements issues early on. Once you complete your analysis, record it in a written document. This becomes the "contract" for creating the product or system that addresses all the needs of your business or your client.

Done by: MA BDA

11

Appendix 2: Work Breakdown Structures Mapping out the work within a project
One of the most popular ways of this is to use a "Work Breakdown Structure". This technique is often used by professional project managers, using formal project planning methodologies. But you'll also find it useful for smaller, less formal projects and even if your job title isn't "Project Manager". These might include a running marketing campaign, managing an office move or even organizing a company "away day". A Work Breakdown Structure is a detailed list of all of the things that need to be delivered and the activities that need to be carried out to complete the project. As shown in Figure 1 below, it's represented as a tree-structure, with each deliverable or activity broken down into further components.

Figure 1: Work Breakdown Structure Format

Done by: MA BDA

12

Appendix 3: Milestone Report Template

Check the next page

Done by: MA BDA

13

Appendix 3: Project Initiation Document

Constructing a PID Although most project-driven organizations have their own templates for Project Initiation Documents, the information contained in those documents is often quite similar, despite variations in the terms used. Here, we work through the most common sections, and look at the information that should be covered in each. Note: Our checklist is for guidance only. In your situation, it may be appropriate to leave some items out and/or add others. Section 1: What? This section tells the reader what the project is seeking to achieve. In it, describe the problem that the project is seeking to solve, as well as a full definition of the project. This section will typically cover the following topics: Background What is the context of the project, and why is the work needed? Briefly describe the idea or problem, and discuss why this project is relevant and timely. The details will come later, so use this section to highlight briefly how this project came to be. Project Definition Purpose: Why are you doing this work? Describe the desired end result of this project. Objectives: What specific outcomes will be achieved, and how will you measure these outcomes? Remember to limit the number of objectives for your project four or five goals are typically enough. Scope: What are the boundaries for this project (for example, type of work, type of client, type of problem, geographic area covered)? List any areas excluded that you believe stakeholders might assume are included, but are not. The more specific you are, the less opportunity there is for misunderstanding at a later stage in the project. Deliverables: What will the project deliver as outputs? Where you can, describe deliverables as tangible items like reports, products, or services. Remember to include a date that each deliverable is expected. You'll use this information to monitor milestones. Constraints: What things must you take into consideration that will influence your deliverables and schedule? These are external variables that you cannot control but need to manage.

Done by: MA BDA

14

Assumptions: What assumptions are you making at the start of the project? If necessary, schedule work to confirm these assumptions.

Section 2: Why? Build a business case to show why your project is going ahead. Describe the effect the project will have on the business, and support this with a detailed account of the risks that should be considered. Business Case Benefits: Why are you carrying out this project, and what benefits do you expect it to deliver? Include information on how these benefits will be measured. Options: What other courses of action were considered as this project was designed and developed? Cost and Timescale: Provide a breakdown of project costs and related financing. Cost/Benefit Analysis: How are the costs of the project balanced against the expected returns? Risk Analysis Risk Identification: Identify the risks within the project, and that you'll either need to manage or accept. Risk Prevention: Describe what you are going to do to mitigate or manage risks. Risk Management: Where you can't prevent risks, what are your contingency plans for dealing with them? What actions will you take should the risk materialize? Risk Monitoring: What processes do you have in place to routinely assess the risks associated with your project?

Section 3: Who? Describe how the project will be organized and managed. Identify reporting lines, and outline specific roles that will be filled. You need to be clear about staff roles so that you don't duplicate responsibilities, and so that everyone is clear about what's expected of them. If this is a long-term project, you may even consider developing job descriptions for team members. Roles and Responsibilities Project Organization Chart/Structure: Create a diagram that shows the lines of authority and reporting for each project team member. Project Sponsor: Who has the ultimate authority and control over the project and its implementation?

Done by: MA BDA

15

Project Manager: Who is the Project Manager, and what are his or her responsibilities? Project Team: Who are the key members of the project team? What are their roles and job descriptions? What are their phone numbers and email addresses? What is their original department or organization? And to whom do they report to on a daily basis?

Section 4: How and When? Provide broad information about how the project will be implemented. Outline how the project will roll out by defining timelines, resources, and management stages. This is a high-level overview that will, as the project proceeds, be supported by more detailed project planning documents. Initial Project Plan Assignments: What major tasks (with milestones) will be completed during the project? Schedule: Provide a report of the estimated time involved for the project. You've probably already prepared a high level Gantt chart or similar schedule, so the PID simply summarizes the anticipated schedule. Human Resources: How many days activity will be needed to complete the project? How many support staff will be needed? Will you need to bring more people onto the project team? Project Control: How will progress be monitored and communicated? Quality Control: How will the quality of deliverables be evaluated and monitored?

Done by: MA BDA

16

Check when PID Item complete Section 1: What is the project all about? Project title Background Purpose Objectives (and how they will be measured) Project scope Exclusions from scope Deliverables (including dates of completion) Constraints Assumptions Section 2: Why should this project go ahead? Business case: Project Benefits Options Cost and Timescale Cost/Benefit Analysis

Risk Analysis: Risk Identification Risk Prevention Risk Management Risk Monitoring Section 3: Who will work on the project? Roles and Responsibilities Project Organization Chart/Structure diagram Names of: Project Sponsor Project Manager Project Team Section 4: How and when will the project be delivered? Initial Project Plan Assignments/Milestones Schedule (Gantt Chart) Human Resource Requirements: Project team Support Staff Additional Staff Project Control: Quality Control Monitoring mechanisms Communication channels and schedules

Done by: MA BDA

17

Appendix 5: Flow chart and Swim Lane Diagram How to Use the Tool Flow Chart:
Most flow charts are made up of three main types of symbol: Elongated circles, which signify the start or end of a process.

Rectangles, which show instructions or actions.

Diamonds, which show decisions that must be made

Within each symbol, write down what the symbol represents. This could be the start or finish of the process, the action to be taken, or the decision to be made. Symbols are connected one to the other by arrows, showing the flow of the process.

Creating and Using Swim Lane Diagrams

The first step to spotting inefficiencies and making improvements is to break down your organization's processes into manageable pieces. If you tried to look at everything at once and in detail, you'd be overwhelmed. So before you get started, it's important to clarify what you are trying to accomplish with Swim Lane Diagrams, and so determine the right areas of focus and level of detail. If you are trying to find strategic inefficiencies, then analyzing every process in detail is unnecessary and cumbersome. Here you might assign each main functional area to a swim lane and look at the interchanges in and between them. This would help you spot disconnects between functional areas of the business. If you were trying to diagnose inefficiencies in your hiring and recruitment process then you would look at specific roles, departments and perhaps some key individuals and assign these to the swim lanes. For a comprehensive approach, you may start by analyzing the processes and organization using high level Swim Lane Diagrams. Then, once you have spotted areas you need to focus on, you can drill down there using more detail diagrams. 1. Determine What You Aim to Accomplish: What business process do you want to analyze?

Is it operational, strategic, functional, etc.? What organization units are involved and what level of detail do you want to analyze these to spot inefficiencies?

Done by: MA BDA

18 2. Clarify the Processes You are Focusing On: A process is defined for this purpose as a series of tasks that have a specific end result, such as hiring a staff member, producing a product, acquiring a new customer. For each process you are analyzing, what is the end result? 3. Identify all Participants in the Processes You are Analyzing: These include all the organization units participating in the processes, and anyone who provides inputs or receives outputs from it. Depending on the level of detail you have chosen, these may be by departments, teams or individual people; or even a computer system that performs certain parts of the process. Which organization units participate?

Where do the inputs to the process come from? Who receives the output of the process?

4. Create the Diagram: List the participants in the far left column of the diagram. Assign each of these participants to a horizontal band (swim lane). It is helpful to assign the swim lanes in sequence, with the first column assigned to the participant who provides the first input. (For customer facing processes, this is often the customer.) 5. List the Step or Activities Required at Each Stage of the Process: Follow through the process sequentially.

Remember you are mapping how the process is currently being done not how you think it should be done. The key to creating a useful diagram is to keep it as simple as possible. Try not to include too many loop backs (unless you are focusing on exceptions) and keep the process mapping moving forward.

6. Analyze the Diagram for Potential Areas of Improvement: Are there any gaps or steps missing?

Is there duplication? Are there overlaps, where several people or teams perform the same task or activity? Are there activities that add no value?

Done by: MA BDA

19

Appendix 6: select stakeholders How to Use the Tool:

The first step in Stakeholder Analysis is to identify who your stakeholders are. The next step is to work out their power, influence and interest, so you know who you should focus on. The final step is to develop a good understanding of the most important stakeholders so that you know how they are likely to respond, and so that you can work out how to win their support you can record this analysis on a stakeholder map. After you have used this tool and created a stakeholder map, you can use the stakeholder planning tool to plan how you will communicate with each stakeholder. The steps of Stakeholder Analysis are explained below: Step 1. Identify Your Stakeholders The first step in your stakeholder analysis is to brainstorm who your stakeholders are. As part of this, think of all the people who are affected by your work, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion. The table below shows some of the people who might be stakeholders in your job or in your projects: Your boss Shareholders Government Senior executives Your coworkers Your team Customers Alliance partners Suppliers Lenders Analysts Trades associations The press Interest groups The public The community

Prospective customers Future recruits Your family

Remember that although stakeholders may be both organizations and people, ultimately you must communicate with people. Make sure that you identify the correct individual stakeholders within a stakeholder organization. Step 2. Prioritize Your Stakeholders You may now have a long list of people and organizations that are affected by your work. Some of these may have the power either to block or advance. Some may be interested in what you are doing, others may not care.

Done by: MA BDA

20 Map out your stakeholders on a Power/Interest Grid as shown in figure 1, and classify them by their power over your work and by their interest in your work.

For example, your boss is likely to have high power and influence over your projects and high interest. Your family may have high interest, but are unlikely to have power over it. Someone's position on the grid shows you the actions you have to take with them: High power, interested people: these are the people you must fully engage and make the greatest efforts to satisfy.

High power, less interested people: put enough work in with these people to keep them satisfied, but not so much that they become bored with your message. Low power, interested people: keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very helpful with the detail of your project. Low power, less interested people: again, monitor these people, but do not bore them with excessive communication.

Step 3. Understand Your Key Stakeholders You now need to know more about your key stakeholders. You need to know how they are likely to feel about and react to your project. You also need to know how best to engage them in your project and how best to communicate with them. Key questions that can help you understand your stakeholders are: What financial or emotional interest do they have in the outcome of your work? Is it positive or negative?

What motivates those most of all? What information do they want from you?

Done by: MA BDA

21

How do they want to receive information from you? What is the best way of communicating your message to them? What is their current opinion of your work? Is it based on good information? Who influences their opinions generally, and who influences their opinion of you? Do some of these influencers therefore become important stakeholders in their own right? If they are not likely to be positive, what will win them around to support your project? If you don't think you will be able to win them around, how will you manage their opposition? Who else might be influenced by their opinions? Do these people become stakeholders in their own right?

A very good way of answering these questions is to talk to your stakeholders directly people are often quite open about their views, and asking people's opinions is often the first step in building a successful relationship with them. You can summarize the understanding you have gained on the stakeholder map, so that you can easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters or your project. A good way of doing this is by color coding: showing advocates and supporters in green, blockers and critics in red, and others who are neutral in orange.

Figure 2 shows an example of this in this example, you can see that a lot of effort needs to be put into persuading Piers and Michael of the benefits of the project Janet and Amanda also need to managed well as powerful supporters.

Done by: MA BDA

22

Appendix 7: Project Benefits

Starting with the End "Benefits Management" is the process by which you ensure that your projects deliver what you want. Done effectively, it helps ensure that your project's deliverables give value to the business, and the appropriate return on investment. In the benefits management process, you answer questions like these: Why are we doing this?

What business objective will this project help to meet? Have we defined all of the benefits we're expecting? Have we justified the time and expense of the project? How will we measure the benefits? Is the project still valid? Are the benefits still relevant?

Investing your time in benefits management helps you reduce the overall risk of the project. It forces you to look at organizational issues that might hurt a project's success, and then deal with those issues in the project plan. After all you begin by knowing what you want the end result to look like, you'll likely improve your ability to predict and avoid many potential obstacles. The Benefits Management Process A benefit is the desired result of a project that was created to meet a particular operational need. For example, a project designed to reduce the time it takes to process an order has benefits such as improved customer service, increased sales, and reduced frustration for sales staff who have to deal with customer complaints. The whole point of benefits management is to make sure that your project provides clear benefits as opposed to simply making sure the project is completed within specific time and resource limitations. So, while the success of project management is to deliver on time and on budget, the success of benefits management takes it one step further to ensure that the initiative delivers the expected results. Here are the main phases of benefits management:

Phase One: Define and develop the benefits

During project initiation: Talk to all stakeholders to figure out which benefits and outcomes each expects and why.

Create a benefits statement.

Done by: MA BDA

23

List the final benefits that you want, and make sure you've distinguished between "must haves" and unaffordable "nice-to-haves". Identify how the benefits are aligned with the company's strategy, and the needs of the business.

Decide what must happen in connection with the project to maximize benefits.

Identify the changes, or other projects, needed to support and achieve the outcome of the main project, and make sure that these are in the plan. For example, do workers need extra training? Do you need a new advertising campaign to tell the market about your new feature? Or do you need to hire additional people, or buy new equipment to take full advantage of the change?

Extend the cost-benefit analysis to include the benefits you've identified. Remember to look for tangible and intangible benefits.

Phase Two: Develop the benefits plan

Again, during project initiation: Look at the overall project plan, and make sure that the appropriate supporting activities are included, so that you can ensure that benefits are achieved on time. Use traditional project management tools, like Gantt charts and PERT charts, to complete and track your benefits schedule.

Watch out for gaps in benefits, as well as additional benefits. Identify who is accountable for delivering these supporting activities. Establish metrics for each benefit, and determine when and how you'll determine that the benefit has been delivered. Determine how the benefits will be reported. You can use milestone reports as well as a benefits dashboard as reporting tools. Include a benefits management summary in the business case for the project.

Phase Three: Monitor the benefits during project implementation

As the project moves forward: Regularly monitor your progress towards delivering the expected benefits.

Modify the benefits plan as needed when the overall project plan changes.

Done by: MA BDA

24

Establish a communication system between yourself and the project manager (if this is a different person). This helps ensure that you routinely discuss and consider the benefits. Provide support to the project team, and use the benefits statement to encourage their work. Watch for "benefits creep" make sure that people's expectations don't grow too much during the project. When you start to expect too many benefits, this can weaken the project's overall impact, and lead to disappointment when imagined benefits are not delivered. If your benefits-required list keeps growing, it's often better to create separate projects for each specific intention and focus. See more tips on scope control.

Phase Four: Complete the project, and review your benefits

Towards the end of the project: Identify the benefits that were achieved, and look for gaps and missed opportunities.

Monitor your workers' ongoing needs to ensure that they continue to enjoy the benefits. Consider setting up a system to communicate future needs. This is a way to collect ideas for future projects. Record what went well and what needed improvement. This supports continuous learning within your organization.

Done by: MA BDA

25

Appendix 8: Post implementation Review

The PIR Process The key to a successful PIR is recognizing that the time spent on the project is just a small part of an ongoing time-line. For people and organizations that will be working on similar projects in the future, it makes sense to learn as many lessons as possible, so that mistakes are not repeated in future projects. And for organizations benefiting from the project, it makes sense to ensure that all desired benefits have been realized, and to understand what additional benefits can be achieved. When to Review A good time to start thinking about the Post Implementation Review is when members of the project team remember the most shortly after the project has been delivered, and when most of the problems have been ironed-out. Start to list ideas and observations while they are still fresh in people's minds. However, to adequately assess the quality of the implementation and complete this process, you'll need to wait long enough for the changes caused by the project to truly take effect. There will probably be a period of adjustment before you can finally review the solution as it was intended to operate: you'll likely need to overcome some of the usual resistance to change, hold people's hands while they operate new systems, and eliminate technical problems that didn't emerge when deliverables were tested. You should therefore typically allow a few weeks, or even a few months, before doing the full PIR. Where possible, allow for at least one, full, successful cycle of business before reviewing lessons learned. What to Review Here are some tips for conducting the PIR: Ask for openness Emphasize the importance of being open and honest in your assessment, and make sure that people aren't in any way punished for being open. Be objective Describe what has happened in objective terms, and then focus on improvements. Document success Document practices and procedures that led to project successes, and make recommendations for applying them to similar future projects. Look with hindsight Pay attention to the "unknowns" (now known!) that may have increased implementation risks. Develop a way of looking out for these in future projects. Be future-focused Remember, the purpose is to focus on the future, not to assign blame for what happened in the past. This is not the time to focus on any one person or team. Look at both positives and negatives Identify positive as well as negative lessons. When conducting the review, include the following activities: Conduct a gap analysis. Review the project charter to evaluate how closely the project results match the original objectives.

Done by: MA BDA

26 Review the expected deliverables (including documentation) and ensure either that these have been delivered to an acceptable level of quality, or that an acceptable substitute is in place. If there are gaps, how will these be closed? Determine whether the project goals were achieved. Is the deliverable functioning as expected? Are error rates low enough, and is it fit for purpose? Is it functioning well, and in a way that will adjust smoothly to future operating demands? Are users adequately trained and supported? And are there sufficiently enough confident, skilled people in place? Are the necessary controls and systems in place, and are they working properly? What routine activities are needed to support the project's success? If there are problems here, how will these be addressed? How does the end result compare with the original project plan, in terms of quality, schedule and budget? Determine the satisfaction of stakeholders. Were the end users' needs met? Is the project sponsor satisfied? What are the effects on the client or end user? If key individuals aren't satisfied, how should this be addressed? Determine the project's costs and benefits. What were the final costs? What will it cost to operate the solution? What will it cost to support the solution in the future? How do the costs compare with the benefits achieved? If the project hasn't delivered a sufficiently large return, how can this be improved? Identify areas of further development. Have all of the expected benefits been achieved? If not, what is needed to achieve them? Are there opportunities for further training and coaching that will maximize results? Could you make further changes, which would deliver even more value? Are there any other additional benefits that can be achieved? Identify lessons learned. How well were the projects deliverables assessed, and how well were timescales and costs assessed?

Done by: MA BDA

27

What went wrong, why did these things go wrong, and how could these problems be avoided next time? What went well, and needs to be learned from?

Report findings and recommendations.

What have you learned from this review? Do you need corrective activity to get the benefits you want? What lessons have you learned that need to be carried forward to future projects? Does this project naturally lead on to future projects, which will build on the success and benefits already achieved?

How to Review
As you perform the post-implementation review, certain methods and practices will help you obtain the best possible information: Define the scope of the review beforehand -The last thing you want to do is to create a political problem. Given the number of people often involved in a project, it's easy to hurt someone's feelings when reviewing the project's success. Clarify your objectives for the review, and make your intentions clear this will better ensure that people share their experiences openly and honestly. Then make absolutely sure that you stick to these intentions, and that people's egos aren't unnecessarily bruised by the process! Review key documents Gather together the key project documents. This will help you assess the project planning process, as well as the actual benefits achieved through the project. Consider using independent reviewers Where possible, use outside people in your review process to get an objective, unclouded view of the project. Some people recommend using only independent people in the review, however, you can learn a lot from the perspectives of those who were directly involved in the project this is why the best strategy is probably to have a balance. Use appropriate data collection Collect information in the most appropriate way, for example, by using interviews and surveys. Also, test the deliverable yourself, to make sure you get firsthand information. Deliver appropriate reports Report your findings, and publicize the results. Remember that the PIR is designed to help project managers conduct more effective projects in the future, as well as to measure and optimize the benefits of the specific project being reviewed. Present recommendations Present the detailed recommendations to the organization and the project leaders, as well as to customers and other stakeholders. Include as many people as necessary so that you keep and apply the bestpractice information in the future.

Done by: MA BDA

28 Appendix 9: Project Dashboard

Done by: MA BDA