Our MSP Foundation and MSP Practitioner courses will teach you about Governance Themes, including Blueprint design & delivery. As well as giving you this theory, our trainers will give you real life examples and case studies, so you’ll be able to put your new knowledge into context straight away!

What goes into the Blueprint?

The Blueprint is a model of how the organisation works, including it’s working practices/processes, the information it needs to function, and of supporting technology needed. The Blueprint designed during the Defining a Programme stage clearly demonstrates what the programme will achieve, and is referred back to throughout the life of the programme in order to maintain focus.

The final Blueprint will usually also include outlines of how the state of operations will be at the end of each Tranche.

The P.O.T.I. model is used for Blueprint design in MSP

• Processes – Business models of operations and functions, and how these will fit with or change operational processes.
• Organisation  - The structure of the programme and how it fits into the organisation as a whole; including staffing levels, roles and skill requirements, the organisational culture, and supply chain details.
• Technology – IT systems, buildings, equipment, machinery, accommodation.
• Information - Informational/data requirements from the programme and business operations, including measures of performance.

The Purpose of the Blueprint

The Blueprint is referred back to during each stage, particularly at the end of each Tranche, and ensures a focus on benefits and the required organisational structure after the programme. Because this goes beyond simple goals or milestones, it means that everyone working on the programme can share the same high-level vision.

As the Blueprint only covers new capabilities, there should be minimal temptation to think of the old/current state of affairs – so everyone on the Programme is looking forward to a shared vision, not back.

What Happens to the Blueprint After Programme Definition

Once the Blueprint has been finalised and the programme defined, the Programme Plan will deliver the state as outlined in the Blueprint, using Gap Analysis – consideration of the differences between the blueprint and the current situation, to plan the programme.

Each Tranche of the programme will deliver part of the future state as outlined in the Blueprint, and each capability is reviewed between the Tranches with reference to the final Blueprint.

When the programme is closed, the current state of affairs is compared to the Blueprint design – of course, the two should match up. Where there are differences, these are recorded as learning points for future programmes or corporate strategy.

The business case is crucial to the MSP framework as it ensures that the programme is the best possible course of action towards progress.

MSP is a defined and controlled methodology for managing programmes, and defining the business case is just one small part of the technique. Our accredited MSP courses will cover this topic in much more depth, along with all the other theory and best practice of programme management.

What is the Business Case in MSP?

The official MSP website defines Business Case Management as “The manner in which a programme’s rationale, objectives, benefits and risks are balanced against the final investment, and how this balance is maintained, adjusted and assessed during the programme.”

In other words, the Business Case is the rationale for the programme in the first place – and is therefore regularly reviewed to ensure the sponsors’ investment is still worth it.

It’s important to always remember that the Business Case covers justification for the existence of the programme itself (and accompanying staff and resources) – the case for any projects occurring within the programme are defined separately, albeit with the programme’s Business Case in mind.

When is the Business Case Defined?

The Business Case first starts to be formed during the Identifying a Programme phase – and becomes part of the Programme Brief along with the Programme Plan, Benefits Realisation Plan and Projects Dossier.

It is defined in full during the Defining a Programme phase of MSP. Each project that then occurs within the Programme Management framework will refer to the overriding business case to ensure its own viability, and the Business Case will be updated accordingly.

For multiple programmes, the business case is defined along with the programme plan, before the first tranche, and before authority has been given for the programme to proceed.

As benefits are realised during Managing the Tranches, justifications for, or evidence against, the business case is recorded.

During the Closing a Programme phase, the business case will be reviewed for the last time, in light of the outcomes of the individual projects – and it may even be updated later on as other unseen benefits become realised.

What Goes Into the Business Case?

The business case contains:

• The benefits of the programme
• The value of these benefits
• Costs involved for the programme itself and the cost of individual projects within the programme
• Details of risk
• Timescales for achieving the defined benefits

How is the Business Case Validated?

As projects within the programme are initiated and completed, the programme Business Case is maintained and updated to ensure it remains viable.

As the Business Case is defined with the Defining a Programme stage, it’s up to the Senior Responsible Owner to ensure that other viable alternatives have been considered, and this process will be documented in order for the Programme to go ahead.

As mentioned above, validation for the Business Case doesn’t just occur before it begins but at all stages of the programme:

• As more details are added to the programme definition, the business case is revisted to check none of these details have detracted from this
• During Managing the Tranches, any evidence against the business case is taken seriously in case it invalidates it
• As the programme is closed, the business case may be validated or otherwise by the outcome of the programme

Below you can see a diagram of how the Business Case evolves in MSP:

MSP training and certification will guide you through APMG best practice for each of these. This will be closely based on the MSP manual, which does emphasise that the profile for each of these must be tailored to the organisation and the specific programme.

The 9 Governance Themes are:

• Vision
• Programme organisation
• Benefits management
• Leadership and stakeholder engagement
• Blueprint design and delivery
• Planning and control
• The business case
• Risks and issue management
• Quality and assurance management

Vision

The vision statement is perhaps the most rigid of the governance themes, and is a document compiled by the Senior Responsible Officer and a team of relevant senior managers and stakeholders. The statement outlines the expected result after the programme objectives are fulfilled.

Blueprint Design and Delivery

This is an extension of the vision statement – a detailed model of the future organisation with ‘gap analysis’ of the differences between that and the organisation as it is now. This gap analysis helps plan and refine the programme.

Organisation & Leadership

This details the structure of the programme and the roles and responsibilities of everyone involved.

Benefits Management

This identifies the benefits of the programme and uses these to create a Path to Benefits Realisation diagram. This clearly displays the steps needed to get from project outputs to strategic objectives.

Leadership and Stakeholder Engagement

This is essential for the success of the programme, and must be planned and carried out in a controlled manner. Stakeholders include anyone with a vested interest in the programme, including employees. Engaging and managing relationships with stakeholders is critical to the success of a programme.

Planning and Control

This usually takes the form of a Programme Plan to detail how the programme will be controlled. It will include resources, risk management, deadlines, scheduling, constraints and individual project details.

The Business Case

The business case puts forward the case for the viability and worth of the programme, and will include details of cost, timescales, benefits and risks. It will be reviewed throughout the programme and regularly updated with new information and developments.

Risks and Issue Management

This is an important governance theme outlining how risks will be identified and controlled, and how issues will be dealt with. It will form the basis of the Issue Log. For more on this, have a look at our article on risk and issue management.

Quality and Assurance Management

This will be ongoing throughout the programme, the strategy for which forms this theme. Quality management ensures the programme achieves its vision statement.

Managing the Tranches is the process that oversees the other two processes of Delivering the Capability and Realising the Benefits.

Managing the Tranches establishes and implements the strategies, procedures and activities that define how the programme will be managed and controlled.

If you would like to learn more about Managing Successful Programmes (MSP), using tranches and other theory, MSP Foundation training may be for you!

What is a Tranche?

A tranche is a portion of something – in this case a group of projects and activities that deliver a step change in capability. During the Managing the Tranches process, after each tranche, End of Tranche reviews can be held to review the benefits in accordance with the business case.

Once the strategies have been implemented, the main function of this process is in monitoring all the programme activity to ensure that things are done correctly to the defined governance.

Below is a diagram showing the major inputs, controls, activities, outputs and responsibilities to Managing the Tranches.

The next diagram represents how the tranches may be arranged, but it is important to note that a programme may run more than one tranche at a time. This will of course increase the complexity and level of risk associated with the programme- but may be necessary in certain types of programmes.

Training in MSP provides principles which can be applied to a wide range of business programmes.

Many businesses fundamentally fail to recognise a programme, and assign the term instead to groups or portfolios of projects.

More accurately, a programme is a group of projects that are all closely related and working towards the same business objective.

Programmes, Projects and Portfolios

It’s crucial that businesses keep sight of the differences between projects, portfolios and programmes. Project management is simply about controlling one project with one overriding objective. Project Management techniques such as PRINCE2 can be used to work with programme management like MSP.

A portfolio is a group of projects, probably in the same business area, which may share some objectives but are not directly related.  The term ‘portfolio’ may sometimes be used loosely as a group of projects within a programme, but is best avoided as it can cause confusion. More information on programme management and project management differences.

Programme management is concerned with controlling a group of related projects with shared objectives. It is important that everyone concerned knows that different processes and experts much be used to manage programmes than who manages projects.

Identifying Programmes

Once a business has identified that they have a group of projects that can be classed as a programme, they draw up a strategic Programme Mandate and Programme Brief.

The programme brief covers:

• What your MSP programme is going to do
• How it will achieve that
• Which employees will be involved in the programme
• Exactly how the programme will be managed
• Justification of why the programme can go ahead

Defining Programmes

The Programme Brief from the identification stage will make the business case that the programme is required. This brief will be the starting point for defining the programme, and also the plans and strategies for how the programme will be governed.

The Programme Definition

The Programme Definition document specifies how the organisation will be changed by the successful programme, and how it will be governed in terms of quality, stakeholders, issue resolution, risks, benefits, resources, planning and control.

It must be approved by the Sponsoring Group and the SRO before the programme can be formally established. Detailed planning is undertaken at this stage to ensure the best – and most realistic – case is put forward.

The Programme Plan document in this definition stage is vital to provide a structured framework for managing the programme and includes:

• Timescales, cost, output and the project dependencies
• Risks and issue management
• A detailed schedule of programme tranches
• Transition plans
• Plans for monitoring and controlling performance and targets

With this in mind, we are giving away an exercise taught on our MSP training courses - the Silicon Beach Training Project Definition & Scope Checklist.

This Project Definition & Scope Checklist can be downloaded and kept for future reference, just click on the link or the image to download it as a .PDF

You can use the checklist to review the Project Definition and Scope Document that you are currently producing.

If you are looking to become a programme manager then the right training is essential. Our MSP Foundation training and MSP Practitioner training courses both have high pass rates thanks to our experienced trainers, small class sizes and dedicated pre course material.

Project Definition

Defining the project is one the most important steps for successful projects. The Project Definition should be clear and accurate to ensure that the targets are hit by the end of the project.

Although defining the project is the project manager’s role, the programme manager has to be aware of the projects they are in control of and must produce a Programme Definition to present to the organisation.

Project Scope

Once you have defined the project you must establish the Scope. The Scope Statement is essential for all projects and is used to outline the desired outcome of the project and the conditions under which the outcome will be achieved.

The Scope Statement should include:

• Justification
• Objectives
• Product scope description
• Product acceptance criteria
• Constraints
• Assumptions

Using the Project Definition & Scope Checklist

Use our Project Definition & Scope Checklist to evaluate your Project Definition and Scope Statement documents to ensure you haven’t missed anything.

It is important to get both documents right at the start to minimise disruption during the project.

Changing the definition or scope can cost both time and money as other aspects of the project must then be changed.

If you like our Project Definition & Scope Checklist then please share it around!

Morale is down, productivity is down and your bottom line is seeing red. While this sounds like an indicator of a bad economy, it may have more microeconomic implications. If you think your business should be doing better than it is, consider looking at your management team. A bad boss or faulty leadership can quickly deteriorate all aspects of your business. Check these seven red flags to see if you management team is failing to encourage and assist your employees.

1. Lack of Communication

Use your ears and not your voice to look for a lack of communication between your managers and employees. Listen to what employees have to say about tasks they have been assigned to and examine the results. Little communication between the boss and the worker can leave questions unanswered, resulting in poor work. Additional lack of communication signs are:

• Limiting answers to yes or no – A manager who does not explain the process or reasoning behind a decision can leave a team of employees confused.
• Ignoring a crises – Management fails when a leader ignores problems or issues that arise in a project making it worse/
• Low employee performance – If you have noticed your employees messing up on routine projects, it could be stemming from a lack of communication from the management.

2. Micromanagement

On the other end of the spectrum, failed management includes leaders who communicate way too much. When a manager assigns a project or task to an employee, he should ensure that the individuals are capable of handling that task. He should set a deadline for when the task needs to be completed and then back off. Micromanagement does the opposite of producing effective results. Signs of micromanagement include:

• Low employee morale.
• Excessive attention to minor details on assigned projects or tasks.
• Managers constantly questioning specific employee’s competence.

If your employees feel claustrophobic and pressured, the quality of the work can go down. Discuss the values of decreasing close supervision with your management team if you notice the above stated signs.

3. High Turnover

Losing employees faster than you can replace them is a big red flag you should address immediately. Not only will your business lose money in looking and training a replacement, it can increase the workload of other employees, lower morale and make your company an unpleasant place to work. Talk to the management team and employees separately to find out the cause for high turnover. If need be, fire the manager who is causing the high turnover. Better to lose one bad manager than several good employees.

4. Harassment Claims/Aggression

Striking fear into the heart of your employee will not get the best value for your money. Your managers should be open to questions and suggestions about specific tasks or projects. If you notice the following in your workplace, it may be time for some management retraining.

• Sharp increase in harassment claims
• Frequent shouting or yelling matches
• Loud obscenities, racial, sexist, or negative religious comments
• Timid or nervous employees
• Threatened employees

Any type of aggression in the workplace is a serious issue and should be dealt with immediately. Ignoring it could cause physical and emotional damage among employees. Counsel your management team and offer the right support to avoid negative consequences in the workplace.

5. Lack of Direction

By definition a leader should instruct employees the general direction they need to take to complete a project giving them the appropriate steps to satisfactorily complete a task or project. Management fails again when employees:

• Do not know how to complete a project or task.
• Clock in time, but do not achieve measurable results.
• Ignore pressing matters and avoid answering direct questions.

Additionally, managers who delegate a large quantity of tasks on to others can cause a failed management system. Managers who procrastinate projects to the last minute bring bad results. A good manager should recognize the skill sets in each employee and assign tasks accordingly to balance the work load.

6. Poor Work Results

A quick look at a red balance sheet can give owners convulsions. However, those who look at and address the reasons a company is not bringing home the green will help them turn a lemon situation into lemonade.

Employees who are not addressing the concerns of clients, producing quality products or not managing their time properly can add up. If you have a manager who is not examining and addressing these issues, something needs to change in leadership. Retrain or hire new manager who can positively get the most out of your employees.

Tip: Read the American Express Business Platinum review to see how using the charge card can help you get the most out of your employees.

7. Change in Personality

Do you have a manager who acts sweet and sickly around you and other higher-ups? Watch out for the suck-ups because they can quickly turn your company into a battleground for inter-office politics. Signs that a manager is acting two-faced include:

• Quick to blame others when something happens.
• Quick to take the all the credit, instead of sharing it responsibly.
• Lying on minor issues.
• Over-promising and under-delivering on a consistent basis

Keep an eye and ear out for other signs of failed management. As you have to be the leader for your manager team, they should be able to look to you as the ideal role model to pass on to employees underneath them.

Cami Hughes is a social media advocate for the US-based small business credit cards website, CreditDonkey.  How do you recognize warning signs for failed management?  Leave a comment below with your tips. 

Image by Dan4th on Flickr.

Take Control

If you don’t take control then somebody else will. As the programme manager you must assert yourself and show that you are in control of each move. Creating clear and precise agendas – starting point, finish point and route – gives you the power. Elements of the process might change but it is still your agenda so you are still in control.

Build Your Network

Networking is crucial in all aspects of life but as programme manager you want to create an elements of trust within the organisation. If the people working under you trust you – based on previous interactions – then you will have a more successful team. Nobody wants to be lead by somebody they don’t know, so get your name out there and network.

Act the Part

Act like a professional and people will treat you like a professional. Don’t act like you’re above anybody else, that just creates friction. Treat your team as partners and they will produce results closer to your vision.

Strike Early

Make decisions before they are made for you and you will remain in control. Pre-empt decisions that will need to be made along the line and you will manage more successfully.

Pick Your Battles

Sun Tzu’s tips for choosing battles are still relevant today:

• Only fight when there is a prize worth fighting for.
• Only fight when you know you will win.
• Only fight when there is no other way of achieving your goal.

Concede if it will help the programme, but do not compromise your authority.

Embrace Ambiguity

Use ambiguity to take control. Use others’ uncertainty to your advantage. Always have the right answers to the questions being asked and you will be seen as an authority figure.

Focus on Outcomes

Whether it is the outcome of an entire project or just one meeting, always have clear goals in mind. If you go into a meeting knowing what you want to get out of it then you’ll get a lot more achieved. Always look forward, not backwards or sideways.

Use It or Lose It.

If you don’t use your power then somebody else will step in. At the helm of a programme you must be seen to be in control and making decisions or the stakeholders may decide somebody else is better suited to the role.

Of course it also helps to be an accredited programme manager. We pride ourselves on the quality of our accredited MSP courses – we keep numbers low and pass rates high!

Programme management is also commonly confused with portfolio management. Take a look at how programme management and portfolio management are different for more information.

Programme Management is about delivering the whole product while project management takes care of individual parts. For example, if a company is to make a new mobile phone the project managers would be supervising individual parts – software, screen, design etc. while the programme manager would supervise all the projects to ensure the the product meets the business requirements and integrate effectively.

Definition

• Project Management is the management of temporary objective with a defined time, cost and output.
• Programme Management is the management of a number of related projects as well as on-going operational work to achieve the operational goals of a business.

Duration

• Project Management has a defined start and end point and so is temporary in nature. Projects are usually short – three to six months.
• Programme Management has a beginning but does not usually end. While programme management can be used to manage a number of related projects it is also used to bridge the gap between projects. Programmes are likely to be over a year in duration and unlikely to have a defined end point.

Focus

• Project Management is focused on a single defined outcome, aligned to the goals of the programme. The objectives of a project are well defined and clear to the team.
• Programme Management is aligned to the goals and strategies of the enterprise. As programme’s are focused on the organisation’s aims their objectives can change over time.

Function

• Project management concentrates on a single function or very limited cross-functionality.
• Programme management is cross-functional, operating across multiple functions of a business.

Risk

• Project risk is well defined and contained within a single project. The main risks are associated with technical success.
• Programme risk is much large and is spread across multiple projects as well as the time between projects. Programme risk involves both technical and business success and so there is more emphasis on possible financial, client and reputation loss.

Stability

• As a temporary activity, projects are relatively stable as they are executed within well defined terms in order to meet the objectives by the end of the project.
• Programmes are more dynamic as they can change depending on changes to the enterprise operations.

Skill Sets

• Project managers require in-depth project management skills with a focus on technical areas. PRINCE2 is the industry standard of project management training.
• Programme managers need a broader range of skills including business and leadership skills. MSP is the recognised framework for programme management and is important for successful programme management.

Since MSP and PRINCE2 focus on providing a framework for projects – concentrating on elements such as engaging stakeholders, change control and risk management – Agile can be used as a partner methodology to plan the actual creation of the project.

But what exactly is Agile Project Management?

Agile Project Management is a method of Project Management which uses iterations of 1-4 weeks to create stages of a product. This is one of the main reasons it remains so flexible – the project only needs to be planned one or two iterations in advance, so any issues which occur can be dealt with immediately, while new ideas can be incorporated without disruption to the project.

Agile also applies a small number of roles to a team, leaving work boundaries largely undefined. This enables further creativity in team members, since they will not see themselves boxed in to a small part of the creative process, and will have to view the project as a whole. It also allows for greater teamwork as team members will no longer be focussed only on their own work.

Agile allows for a great deal of collaboration between the project team and its business partners. This is partly due to the iterative process, which gives stakeholders the opportunity to see how the project is developing in real terms from a very early stage. The iterative process also permits stakeholders to start reaping the benefits of the project at an earlier stage, since each iteration may lead to new product. This has the benefit of increasing stakeholders’ interests in the project.

Agile Project Management methods come with a great number of benefits. Teaming your MSP methods with Agile methods can be the most practical way to make your project more flexible, more creative and more productive.