Prince2 Project Management Processes Series – Directing a Project (DP)

In the next part of our series, we look at Directing a Project. Whilst day to day management of a project is given to the Project Manager, it is key that the Executive exercise overall control and be responsible for making key decisions i.e the Project Board – and this falls within the scope of “Directing a Project”. Directing a Project as a process, starts after “Starting Up a Project” (SU) and continues to run until project closure.

The key steps involved in this process are:-

  1. Confirm the project organisation
  2. Agree the project objectives
  3. Approve the plan to generate the “contract for the project”
  4. Approve the “contract”
  5. Approve each stage of the project
  6. Make decision on any major problems
  7. Keep senior management informed
  8. Confirm the correct closure of the project

Each of the steps are applied at different points within the project as shown in last weeks diagram. DP4 – Giving Ad Hoc Direction is clearly seen to be running throughout the project. Authorising Initiation (DP1) is followed by Authorising the Project (DP2). Authorising a Stage or Exception Plan (DP3) usually occurs several times in any one project and eventually leads to Confirming Project Closure (DP5).

The core of Directing a Project, is defining responsibilities for the Project Board and the process also gives legitimacy and direction to the project and its control throughout its life. The main Project Board responsibilities are summarised:-

  • Approving the Project Brief and authorising initiation.
  • Authorising the Project Initiation Document, commonly known as the “PID”, and taking ownership of the project.
  • Checking project status at the end of each stage and authorising continuation to the next stage.
  • Providing management direction and guidance to the Project Manager.
  • Liaising with programme management.
  • Confirming project closure

There are projects where a Project Board is not clearly identified and not empowered, leaving all the responsibility to the Project Manager. This usually happens on “smaller” projects and is a practice not to be encouraged as this leaves too much responsibility on the shoulders of one person. Without the direction and guidance of the Project Board there is an increased risk of project failure.

Information contained within this post is copyright to Crown, OGC

Agile Software Development Overview

Agile Software Developmen is a framework for software engineering/development projects and not a methodology in itself. Some of the methods that fall under Agile are Crystal Methods and Scrum. Agile methods attempt to minimise risk by developing software in short iterations, lasting one to four weeks. Each iteration is like a mini-project in its own right, and includes all the tasks necessary to release the increment of new functionality i.e. planning, requirements analysis, design, coding, testing, and documentation (although Agile is usually quite light on the documentation side).


Whilst one iteration may not add enough functionality to warrant releasing the product or newer version, it is usually the intention at the end of an iteration. At the end of every iteration, the project team re-evaluates project priorities to plan the next iteration.Agile methods emphasise the need for quick and open communication, preferably face-to-face, with the team being located in a ring fenced (bullpen) zone – this includes ALL the people necessary to finish the software e.g. programmers, product managers, business analysts, clients, project manager, designers, testers, and writers.

The diagram below demonstrates a typical agile (iterative) development process.

Figure 1
Figure 1

References:-
Hung, T (2007) Figure 1. Software Development Process Available from: http://cnx.org/content/m14619/latest/ (Accessed: 22 February 2009)

Prince2 Project Management Processes Series – Introduction

Prince2 has eight management processes, each of which have a particular emphasis during the project life cycle. The processes are not necessarily sequential, for example, directing a project is applied throughout the project life cycle) so the sequence in which you would apply the process would depend on your individual project. The key to the successful use of these processes is knowing when and how extensively each process should be applied to your project. Each process has several sub-processes (or steps to follow) contained within them. As part of this series I will go through each of the eight processes in detail.


The Eight Prince2 Management Processes:-

  1. Directing a Project (DP)
  2. Starting up a Project (SU)
  3. Initiating a Project (IP)
  4. Controlling a Stage(CS)
  5. Managing Product Delivery (MP)
  6. Managing Stage Boundaries SB)
  7. Closing a Project (CP)
  8. Planning (P)

For the purposes of my blog posts I have followed standard Prince2 abbreviations e.g. when I refer to DP3 this would be step 3 in the “Directing a Project” process. The diagram below gives you an idea of how the processes work together generally.

Prince2 Project Management Processes
Prince2 Project Management Processes

Over the next eight weeks, there will be one post for each process and then probably a summary post for the series. After this I plan to move onto the Prince2 concepts but feel free to leave a comment or email me if you would like to see something else discussed.

Please note all Prince2 diagrams are drawn up by myself but they are copyrighted to Crown in consultation with the OGC (www.ogc.gov.uk)

The Scrum Team – how to maximise productivity

Scrum is a project management methodology often used in software development and sometimes web development where multiple product increments are anticipated.

In Scrum, the team itself figure out how to maximise productivity.  No managers allocating tasks – the job of planning and executing all the tasks belongs solely to the team.  This way, each team member can have a say in what tasks need to be done and by when.  The Scrum Master is only there for advice and guidance.

Scrum has a 30 calender day Sprint (cycle). The team selects which Product Backlog to work from and works uninterrupted on that particular Backlog for 30 days. Once a backlog is selected the team are committed to turning it into a product increment within the 30 day period.

The key to maximising productivity here is that the scrum team manages itself. Those not used to working in a scrum environment may initially be confused by this, and await task allocation by a Project Manager. However, they will soon learn that the Scrum Master doesn’t do this but that he/she will be on hand to guide them in managing themselves and committing to delivery.

At all times, the scrum team must be encouraged to act together as one in order to ensure the product increment is ready at the end of the Sprint.  Sprint Reviews are helpful to ensure everyone is still on track.

*TRY COPERNIC DESKTOP SEARCH NOW*

FREE 30-day trial! Stop searching and FIND.
Voted best Desktop Search application. Click Here

Managing Your Website Development eight Easy Steps to Project Management

Author: projectmanuk

Managing your website development need not cause you sleepless nights providing you learn the secrets of successful project management. Perform the best practices in project management and give your project the best chance of success.

Define objectives

Objectives guide everyone on the project to your final goals. Are your objectives to sell your product online, to provide customer support, to promote investor relations? Carefully decide and clearly document your objectives.

Decide the critical success factors – the things at the end of the project which tell you if you’ve been successful. Make them measurable so you know if you’ve achieved them. For example, the website development should result in an increase in online sales of 25% by year end.

Stakeholder analysis

A stakeholder is someone with an interest in your project’s success (or failure). Decide who they are and whether they support your project. Perform stakeholder analysis by classifying them (high or low) according to how motivated they are in helping (or blocking) your project and how influential (high or low) they are.

Highly influential and supportive people are your allies. Gain their support whenever you can. Aim to reduce the influence of people who are both highly influential and against your project as these people could act to damage your project.

During your stakeholder analysis, draw up strategies for dealing with each group of stakeholders.

Define deliverables

Deliverables are tangible things produced during the project. Talk with key stakeholders to help define deliverables. Will your website design include web page layouts and sitemap for use by the programming team? What is the content for each page? Write all this down.

Key stakeholders must review and agree the deliverables accurately reflect what they expect to be delivered.

Project planning

Define how you will arrive at your objectives. This involves planning how many people, resources and budget are required. If delivering this in house, decide what activities are required to produce each deliverable.

For example, you might decide a web designer will develop page layouts and navigation diagrams. You might decide the marketing team will supply all product details and photographs. You might decide the finance manager will set up merchant and payment gateway accounts to enable e-commerce transactions via your website. If outsourcing work, specify exactly what the sub-contractor should deliver.

Estimate the time and effort required for each activity and decide realistic schedules and budget. Ensure key stakeholders review and agree the plan and budget.

Communication planning

Hold a kick off meeting with the team and explain the plan. Ensure everyone knows exactly what the schedule is, and what is expected of them.

For example, the web designer needs to know that he is to produce page layouts and navigation diagrams based upon the marketing manager’s requirements. He needs to know his expected start and end times.

Share your project communication plan with the team. This should include details of report templates, frequency of reporting and meetings, and details of how conflicts between teams and their members will be resolved.

Project tracking

Constant monitoring of variations between actual and planned cost, schedule and scope is required. Report variations to key stakeholders and take corrective actions if variations occur. To get a project back on track you will need to juggle cost, scope and schedule.

Suppose your programmer hits technical problems which threaten to delay the project. You might recover time by re-organising or shortening remaining tasks. If that’s not possible, you might consider increasing the budget to employ an additional programmer, or consider reducing the scope in other areas.

Be aware that any adjustments you make to the plan might affect the quality of deliverables. If you need to increase the budget, seek approval from the project sponsor.

Change management

Once started, all projects change. Decide a simple change strategy with key stakeholders. This could be a committee which decides to accept or reject changes which comprises of you and one or more key stakeholders.

Assess the impact of each change on scope, cost and schedule. Decide to accept or reject the change. Be aware that the more changes you accept the less chance you have of completing the project on time and within budget unless you reduce scope in other areas.

Suppose the marketing manager wants to add a popup window to display full size photographs of products. Assess the impact of this change. You might need to remove some remaining tasks to include this change and stay within budget. Or, it might be impossible to include the change without increasing the budget or schedule.

Don’t blindly accept changes without assessing the impact or your project will overrun.

Risk management

Risks are events which can adversely affect the success of the project. Identify risks to a project early. Decide if each risk is likely or unlikely to occur. Decide if its impact on the project is high or low.

Risks that are likely to occur and have high impact are the severest risks. High impact but unlikely risks, or low impact but likely risks pose a medium threat. Unlikely and low impact risks pose the least threat.

Create a mitigation plan of the actions necessary to reduce the impact if the risk occurs. Start with the severest risks first, then deal with the medium risks. Regularly review risks. Add new ones if they occur.

Suppose the marketing manager cannot decide what he wants from the website. Without knowing what the marketing manager wants, the team cannot deliver a website to meet his expectations. You assess this risk as highly likely to occur and having high impact. Your mitigation plan might be that the web designer develops page layouts to be reviewed by the manager early in the project.

Summary

Performing best practices in project management will give your website development project the best chance of success.

Article Source: http://www.articlesbase.com/project-management-articles/managing-your-website-development-eight-easy-steps-to-project-management-586725.html

About the Author:

Simon Buehring is a project manager, consultant and trainer. He works for KnowledgeTrain which offers training in project management and PRINCE2 training in the UK and overseas. Simon has extensive experience within the IT industry in the UK and Asia. He can be contacted via the KnowledgeTrain PRINCE2 project management training website.