Home HOME NEWSLETTERS
News
Print E-mail

What is a project and what is a programme?

 

 

Projects

Programmes

Definition

 

‘A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case.’

‘A programme is a temporary flexible organization structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits relating to an organization’s strategic objectives.  

Characteristics

·   Driven by deliverables

·   Has a defined start and end (finite)

·   Bounded and scoped deliverables

·   Delivers product or outcome

·   Benefits usually realized subsequent to project closure

·   Shorter timescale

·   Driven by a desired ‘end state’ vision for the business

·   No predefined path

·   Delivers changes to the business capability

·   Coordination of products/outcomes of a number of related projects

·   Benefits realized during the programme and afterwards

·   Longer timescale (may have a lifespan of several years)

Management focus

·   Detailed specification of how product/s will be created and delivered

·   Control of activities to produce products

 

·   High-level specification (of why/what)

·   Stakeholder management

·   Benefit realization

·   Manages dependencies between related projects

·   Manages change acceptance and transition management

·   Integration with corporate strategies

 

References:

 1.   Using PRINCE2and MSP® Together by Andy Murray (TSO, 2010)

2.   Managing Successful Programmes (TSO, 2007)

3.   Managing Successful Projects with PRINCE2 (TSO, 2009)

 
Print E-mail

PRINCE2® & AGILITY

 

PRINCE2® stands for "PRojects IN Controlled Environments".  This emphasis on control is one of its strengths.  It is a generic project management method for exercising control over a project's startup through to its closure.  It had its origins in IT, but has evolved over the past two decades so that it can now be applied to any project.

 

One key control is the Product Description - where you define what you want to produce before any work is carried out.  However, that does not work for all products.  Some products evolve during their development.  Customer needs might change during development requiring quick reaction by the production team.  Detail emerges during a project which will prompt change that needs to be dealt with ‘on the spur’ within the project.  This detail and change requirement will not have been foreseen at the outset of the project.  For example, software development and website creation prefer a more “agile” approach.  Outputs are defined in advance, but the approach taken to achieve those outputs may need to be very flexible.  

 

Standard PRINCE2® does not offer that level of flexibility as it is not prescriptive regarding the product delivery method.  The approach to product delivery will differ from Mining to IT to Construction, and even from product to product.  PRINCE2® does advocate that the method be tailored to suit specific project requirements.  Factors that will play a role here are, amongst others, the scale of the project, solution complexity, project type and lifecycle model.

 

In response to the above, Agile development methods, such as DSDM, SCRUM and XP arose to deal with changing requirements more effectively and quickly, particularly from a software development viewpoint.  These methods cover in more detail the day to day activities such as sprint planning, daily meeting structure, timeboxing, etc. and provides for several roles that operate at the product delivery level. 

 

DSDM stands for Dynamic Systems Development Method.  It is an Agile project framework, with guidance to achieve on-time and on-budget delivery to satisfy a business objective.  It gives more attention to the product delivery side of a project and allows for greater flexibility.  It focuses on the early delivery of real benefit to a business, user or customer whilst ensuring that the project remains strategically aligned.

 

SCRUM operates at the Team Manager level.  SCRUM adds guidance in product production.  Fast and effective delivery is the aim.  Changes are done in small steps when reality requires it.

 

XP stands for Extreme Programming and is closely associated with software development.  It advocates frequent “releases” in short development cycles to improve responsiveness to changing customer requirements – inevitable in most projects.

 

Both PRINCE2® and Agile methods have their pros and cons.  It is often perceived that PRINCE2® is process-heavy and that Agile is process-light, and they are therefore totally opposite in intent.  Agile methods do not have comprehensive cover for overall project management.  However, PRINCE2® should not be seen as an impediment to Agile.  Rather, it can enable more flexibility, but in a disciplined way.  PRINCE2® is primarily intended to be a high-level governance process that is innately independent of the lower-level process used on a specific project.  It should therefore be able to accommodate an Agile implementation approach.

 

The hurdle facing practitioners in many organisations is how to make the two work together effectively.  Effective integration requires that the benefits of each can be achieved without diminishing the benefits of the other.  One is a project management method for exercising control; the other is a development method for managing change.  This makes Agile a natural fit to the PRINCE2® process of ‘Managing Product Delivery’.  The team works with Agile, the project manager mainly works with PRINCE2®.  The two compliment each other and should result in a good management method for control within a changing environment.


Conclusion
:

In short, Prince2® offers great control at the project level.  Agile brings autonomy and ‘agility’ at the product delivery (team) level.  The combined use of PRINCE2® and an agile approach to product delivery can provide the best of both worlds – robust project governance and an excellent process-driven framework that delivers the right solution to the customer at the right time.

 

Resources:

1.   PRINCE2 combined with SCRUM.  Martin van Borselaer (2010)

2.   PRINCE2 + AGILE = Common sense?  Craig Cockburn (2008)

3.   Prince2, Agile, SCRUM – are they connected?  The Dark Knight (2009)

4.   http://www.dsdm.org

 

 
Print E-mail

How PRINCE2® helps to avert project failure

 

The number of reasons why projects fail is almost endless. Even with the best of intentions and carefully crafted plans, projects can head south if they are not managed properly. Applying the world-renowned PRINCE2® methodology on your projects can go a long way in ensuring project success.

The table below sets out how PRINCE2® counters some of the most common reasons for project failure.

REASON FOR FAILURE

PRINCE2® COUNTER

Poorly managed

Poorly defined roles and responsibilities

Project Management Structure for project created in pre-project Start Up process.

Clear role descriptions for each person in the Project Management team setting out their responsibilities, goals, limits of authority, relationships & reporting lines

Lack of a solid project plan

Project Plan for project as a whole created during Initiation Stage, reviewed & updated by Project Manager at the end of each management stage.

Lack of pro-active management initiatives to combat project risk

Risk Management Strategy compiled in Initiation stage includes procedure, timing of risk activities and roles & responsibilities.

Executive & Project Manager must drive pro-active risk management

Poor communication

Communication Strategy with proper Stakeholder Engagement Plan compiled during Initiation Stage, revised at the end of every management stage

Overruns of schedule and cost

Business Case compiled to ensure business justification for project during Initiation Stage based on Project Plan, reviewed at each management stage boundary; plans done for each stage of the project; project tolerances set for time and cost

Scope creep

Undefined objectives and goals

Project Brief created pre-project in Start Up process; expanded into detailed Project Initiation Document during Initiation Stage to clarify scope

Ignoring project warning signs

Project Manager must review stage progress continuously in Controlling a Stage Process

Reviews done at the end of each project stage by Project Board before authorising next stage

Lack of user input

Inadequate or vague requirements

Meeting end user expectations

Senior User on Project Board assists in specifying user requirements

Customer Quality Expectations defined in Project Brief with measurable Acceptance Criteria in Start Up process

Eventual Users involved in quality control activities

Unrealistic timeframes and tasks

Estimates for cost and schedule are erroneous

Plans compiled for each Stage of the project – shorter planning horizon

Project Assurance advisors to advise whether plans are realistic

Project Board must approve project - & stage plans

Well-defined planning procedure applied, utilising the Product-based Planning technique

Insufficient resources (funding and personnel)

Appointees to Project Board must have necessary authority to commit resources to project – both (financial & personnel);

Executive responsible for project funding arrangements as set out in Business Case

No change control process

Configuration Management Strategy created in Initiation Stage contains formal Change Control Process

Inadequate testing processes

Quality Management Strategy created in Initiating a Project stage contains testing processes/methods that must be applied to each product to be delivered by project

Lack of management commitment

Corporate/programme management appoints Executive for project

Executive looks after business interests & must ensure project gives value for money

Lack of organisational support

Project Executive must take care of Business interests on project

Universal templates and documentation

PRINCE2® not template driven; supports tailoring of documentation to project needs

Stakeholder conflict

Stakeholder Engagement Procedure implemented

Competing priorities

Cost and risks weighed up against benefits to ensure continued business justification for project; benefits defined at Initiation Stage

Business politics

Project Board has responsibility and authority for the project within the instructions from corporate/programme management in Project Mandate

Lack of prioritisation and project portfolio management

Projects prioritised based on Cost/Risks vs Benefits-analysis of project to client as set out in Business Case

Bad decisions

Project Board is main project decision-making authority

Tolerances set for project board (by corporate/programme management), project manager (by project board) & team managers (by project manager)

If any tolerance is forecast to be exceeded, the problem must be escalated to higher management level

References

 1.   Why projects fail - Oracle

2.   Reasons Why Projects Fail - Tom Carlos

 
Print E-mail

A Project Management Office – What & Why?

 

A Project Management Office can significantly improve the delivery of projects for an organization.  Surveys show that organizations with PMO’s have higher performance measures than those without PMO’s and that reporting, monitoring and controlling, and the use of templates and methodologies rank high in PMO functions.  Given the appropriate governance, it can improve communication, establish an enterprise standard for project management and help reduce the disastrous effect of failed development projects on enterprise effectiveness and productivity.  PMO’s can save organizations money by enabling better resource management, reducing project failures and supporting those projects that offer the biggest payback.

 

 

What?

A PMO is an organizational unit to centralize and coordinate the management of projects.  Its goal is to apply a consistent project management methodology across an organization.  It functions as a shared competency designed to integrate project management within an enterprise.  A PMO can be a key resource in establishing an enterprise competency in project analysis, design, management and review.  

 

When should an organization consider setting up a PMO?

An organization should consider setting up a PMO when projects become a major portion of the work the organization performs.

 

Popular PMO models:

·       Consulting capacity - providing project managers in business units with training, guidance and best practices;

·       Centralized version - with project managers on staff who are loaned out to business units to work on projects.

 

Basic organizational styles for a PMO:

There are three basic organizational styles for a project management office.  Each has unique functions that define its role within the project development-to-management life cycle.

·       The project repository - the project office simply serves as a source of information on project methodology and standards.

·       The project coach model – in addition to being a repository, project management practices are shared across business functions and the project office coordinates communication.  Best practices are documented and shared, and project performance is monitored actively.

·       The enterprise project management office - the most permanent, consolidated organizational model concentrates project management within a project office. This implies direct management or oversight of projects wherever they occur within the enterprise.

 

Designing a PMO:

It is important that the PMO structure fits in closely with the company's corporate culture.  The PMO that is established must be one that makes the most sense for the particular organization.

 

Defining a logical PMO organization:

Before designing a PMO it must be defined how it will function logically within the organization.

 

The following major components define a logical PMO.

·       Sponsor:  The sponsor is the person responsible for the PMO funding and, in many cases, the sponsor is the manager to whom the PMO reports.  Sponsors are absolutely critical for a culture change initiative such as the PMO.

·       Stakeholders:  Any people or groups (internal and external) who have an interest or a partial stake in the products and services the PMO provides.

·       Clients/customers:  While there may be many stakeholders, it is important to recognize who the clients are and how the PMO will focus on helping them meet their project and business objectives.

·       Objectives:  Concrete statements describing what the PMO is trying to achieve.  A well-worded objective will be specific, measurable, attainable/achievable, realistic and time-bound.

·       Products/services:  Define tangible items that the PMO produces as the result of a project.  The PMO achieves its objectives through the creation of products and the delivery of services.

·       Transitional activities:  These are the specific activities and projects required to implement the physical PMO.

·       Other aspects:  The PMO vision, principles, goals, objectives, skills, roles and responsibilities.

 

Benefits a PMO provides to an organization:

·       Rigorous PM methodology: All project management activities follow industry standard guidelines e.g. PRINCE2®, PMBOK, etc.

·       A resource pool of PM's: Project managers are 100% dedicated to management.  More even deployment of project management resources.

·       Templates: All projects will have a complete set of supporting documents available that have the same organizational look-and-feel.

·       Processes: Uniform ways of managing schedules, costs, risks, communications

·       Metrics: Consistent quantitative measures used to determine performance of projects

·       Knowledge base repository: Knowledge sharing between projects is encouraged, e.g. lessons learned, best practices, past risks etc. 

·       Standardized tools: Industry-standard project management software.

·       Mentoring: Experienced project managers can offer guidance to junior project team members.

 

Ants PM T&D consulting approach:

ANTS PM T&D can assist your organisation in establishing a Programme Office to oversee and provide ongoing support to a portfolio of projects, or a Project Support Office for a stand-alone project.  Ants will assist you to identify the project management needs of your organization.  We will advise you on the optimum organisational structure and size of your project office and will assist with the training of staff.

 

 

References

1.   PMD Consulting, “The Benefits of a Project Management Office”

2.   D. Bradbury (2005), “PMO: What is it and do you need one?”

 
Print E-mail

Warning from APMG

As you are thinking of taking a training course APMG strongly recommends that any training you receive is through an ATO (Accredited Training Organisation).

Only ATOs and their authorised affiliates have licenses to offer training courses that incorporate official OGC trademarks, brands and copyright material.

ATOs have been fully accredited by APM Group. The accreditation process involves a rigorous assessment of the organisation’s management systems, course materials and trainers, assuring the quality of training provided.

Ants PM T&D is an Affiliate to CUPE UK and as such is authorised to deliver PRINCE2 training courses leading to the official PRINCE2 examinations.

All our trainers have practical experience in Project Management.

http://www.apmg-international.com/AccreditedOrganisations/ANTSProjectManagement.asp


 

 


PIAB Free Software

Banner

Google Banner


training venueIn-house Courses
If you have 6 or more people to train then an in-house program may be a more cost effective option. Contact us for our in-house course pricing.

canakkale canakkale canakkale truva search