ITIL is the acronym for the "IT Infrastructure Library" guidelines developed by the CCTA (now OGC) in Norwich, England, for the British government.

Today, ITIL is the de-facto global standard in the area of service management. It contains comprehensive publicly accessible specialist documentation on the planning, provision and support of IT services. ITIL provides the basis for improvement of the use and effect of an operationally deployed IT infrastructure.

IT service organisations, employees from computing centres, suppliers, specialist consultants and trainers took part in the development of ITIL. ITIL describes the architecture for establishing and operating IT service management.

The internationally recognized ITIL®-logo has adorned the covers of ITIL® books for years. The familiar diamond consisting of a number of smaller diamonds is now internationally well-known.

But very few people remember the original meaning of the logo. ITIL® supporters from the very beginning asserted that the diamond symbolizes the coherence in IT infrastructure. They believe the four fields represent the four main subject areas in ITIL®: Service Support, Service Delivery, Infrastructure Management and IT Management. However, the square fields around a central area 'service provision' also symbolize the four parties involved in the ITIL® standard: in the center ITIL® literature (with OGC as owner), around the center the users (represented by ITSMF), the examination institutions (e.g. EXIN) and finally the trainers and suppliers of ITIL® related services.

Setting goals is easy but achieving them isn't.

That's why setting "SMART" goals - Specific, Measurable, Achievable, Realistic and Timely - is the first step in making your goal a reality.

Make your goal as Specific as possible and express it in positive terms. Do you want to stop losing money or do you want to start making money? How much money do you want to make?

How do you Measure success? You'll need a way to evaluate your progress and determine if you're moving towards your goal. For example, if you want to improve your finances, then you should have a way of keeping track of income and expenses.

Is your goal Achievable? Consider whether you have the resources necessary to achieve your goal. If not, you need to determine if you can assemble everything required to streamline your process. Remove any obstacles before you get started!

Realistic goals are achievable goals, unrealistic goals are just dreams. It's not necessary to be negative but take time to honestly evaluate whether you're being realistic. Losing 30 pounds in 2 weeks is not impossible but it's not very likely and certainly not healthy.

Make your goal Timely by stating a due date for your goal AND the action steps involved in achieving it.

Align your goals with your values.

If your goal doesn't reflect your beliefs and character then you'll have difficulty achieving it. And even if you do manage to get what you want, you won't be very happy.

Set a goal which is meaningful to you and be clear about the consequences of your outcome.

Share your goals with three to five key people.

Not everyone needs this strategy with every goal but almost everyone can benefit from it at some point.

Finding supportive, positive people is key because you certainly don't need anyone sabotaging your progress.

Assemble everything you need before you need it.

This prep work is vital in eliminating the frustrating and time consuming "running around" which can derail your progress later on.

Minimise potential challenges.

There are 3 key ways to prevent overconfidence and poor planning from creating obstacles down the line:

• Create a complete, measurable, action plan which includes all the steps necessary to achieve your goal. Don't forget due dates for each step.
• Incorporate all your actions into your schedule. Add them to your calendar with anywhere from 10-20% flextime to help you control any unexpected delays.
• Regularly evaluate your progress. You may need to make changes or adjustments as your project takes shape. Anticipate them so you won't get blind-sided.

Complete at least one action per day.

Consistent actions will propel you towards your goal. Even choosing a small task will make a dent in your to-do list and may motivate you to do even more.

Establish a support system.

Who or what can provide you with encouragement, advice, healthy feedback or a willing ear?

Reward Yourself.

Don't wait until you achieve your goal, especially if it's a long-term one. Reward yourself as you reach certain milestones. Something as simple as scheduling time for yourself or perhaps a special treat that you've felt guilty about indulging in can keep you motivated to keep going.

Applying Real-World Business Management By Exception

One of the key principles for project management success is ensuring that the PM responsibility must be matched by equivalent authority. The PM can’t be made responsible if they don’t have the ‘clout’ to make things happen.

Each individual on the project, and that includes the project manager, must be provided with a clear understanding of the Authority, Responsibility, and Accountability given to them so that their work can be accomplished.

Design Of The Project Organization

When designing the Project Team, start with standard roles such as user representative, hardware engineers, and so forth. Sit down and agree with the individual what responsibilities they will have, and what levels of authority for carrying out their work.

Make sure that these balance. Beware of giving someone (especially yourself!) lots of responsibility but not enough authority to carry out their responsibilities.

A useful one-on-one technique I have used in the past to generate quick agreement is to take a flip chart and draw a vertical line down the middle: At the top of the left column write “This is what I expect of You” and on the right hand column “This is what You can expect of Me”

Do it in any way that feels comfortable (I usually like to do all the writing and let the other person freely give me their thoughts).

It’s a contract for working well together.

But here's the thing, you MUST also do it for management above you. As the Project Manager, you are responsible for delivering the project to times, coast and quality - but senior management have their responsibilities to the project as well. And these need to be agreed. Here are some examples:

• Who 'owns' the Business Case - it's not the Project Manager!
• Who is responsible for agreeing the User Requirements and signing acceptance of the project deliverables - it's not the Project Manager!
• Who owns the resources - it's not the Project Manager!
• Who has the authority to approve Requests For Change or Off Specifications - it's not the Project Manager!
• Who approves all Plans and 'underwrites' the project - it's not the Project Manager!

Also, beware of stakeholders who see themselves as ‘passive customers’. Be clear that if they are to be any part of the approval process within a project, they must become Active Participants. And that means getting involved early and contributing - and having responsibilities!

Each individual within the organization needs to have three key criteria agreed. So let me start by nailing down what these mean:

Authority. The power granted to a person so that they can make decisions that others are expected to follow. The position or role that a person holds is the usual way that authority is granted.

Responsibility. The obligation a person has to perform their assignments effectively.

Accountability. This means that the person is totally answerable for satisfactory completion of a given assignment.

These three attributes are vital if a project and business management is to complete successfully.

Starting at the beginning, it must be unfair if, after sign-off, the project manager is not allowed to respond to situations. In effect, their hands are tied – how can anyone manage in such as situation?

So the Project Plan is signed off, a budget is agreed, and an end date set. The first mistake senior management make is by stating things such as “I have now approved your plan and I expect you to deliver against it” So nothing can ever change – the project manager isn’t allowed to react to risks and changes.

And of course, the estimates contained within the Plan were perfect, customers never change their minds, problems never occur, the world never changes, and Santa Clause does exist!

But hold on; look on the other side of the coin.

Senior Management within the organization are responsible and accountable for some aspect of the business. They are investing in projects to help optimise what they are responsible for. If it was YOUR money – wouldn’t you want to tie the project down?

Luckily there is a middle ground – a way that makes total sense providing organisations are mature enough to use it.

Just suppose that when a Plan was agreed, management gave the project manager some degree of flexibility (in the form of an agreed deviation from Plan), that management could tolerate. This agreed flexibility would be the PM’s playground that allowed them to do their job.

But what should happen if the PM suddenly forecasts that these deviations will be exceeded? Why of course, they must bring it to the attention of higher management and seek guidance.

But that last paragraph sounds like senior management have abdicated their responsibilities. What I mean is, once the Plan is signed off and the deviation is set – they can disappear off to the golf course until the PM tells them the project is completed.

No, not quite. Senior Management would want a regular report of ACTUAL performance against plan showing the allowed deviations. It allows them to question and advise the PM should they wish to do so. And they are safe in the knowledge that if, between these regular reports, the PM forecasts a significant deviation, it will be immediately brought to their attention.

Welcome to Management By Exception. Vital to organizational business management within the project AND central to Management By Exception.

That’s the principles – time to get specific.

Depending on your business you may use your own cultural names for the various roles that make up a project management team. Here are mine – feel free to change the role titles appropriate to your organisation.

The Project Board are appointed to provide authorization and direction, and the project manager (who reports into the Project Board), is responsible for day-to-day management of the project.

Now, on the project board are three roles, the Executive (owns the Business Case, and has the final say in terms of authority), the User Representative role and the Supplier Representative role.

Having approved the Project Plan, the Project Board need to set an acceptable deviation – this is called Tolerance.

Now, Tolerance can be time, cost, quality, scope, risk, benefit, in fact, any suitable metric. As a simple example, let’s assume Tolerance figures are given as plus/minus 10% deviation of the budget and project end date.

What this means is that the project manager can manage in the normal way with the AUTHORITY to take any appropriate management action AS LONG AS TOLERANCE IS NOT FORECAST TO BE EXCEEDED.

At the time of the Plan being approved, this Tolerance is set, along with the regularity of reports and their contents from the project manager.

Okay, let’s imagine we are part way through the project, and to our horror, we see that the project is forecasting to come in 15% over budget. This triggers the exception process, and the project manager must escalate the situation to the next higher level within the management organization - the Project Board.

Notice that we don’t wait until the deviation has actually happened, because it will be too late for pro-active actions to be taken.

The Project Manager will inform the board by an Exception Report (this could be given verbally – but I would want it in writing!)

The Exception Report will contain the following information:

• A description of the cause of forecast deviation from Tolerance.
• The impact or consequences of the deviation
• Available Options to minimise the deviation or remove it completely
• The impact or effect of EACH option on the Business Case, Risks, and Tolerances
• A Recommendation with reasons, of the best option to take

This is sent to the project Board who need to make a decision on one of the options.

Note that one of the options could be to shut the project down prematurely.

The project board level of the organization, will now ask the project manager to draft a new Plan based on the chosen option and this is reviewed by them. A decision is made to approve the new plan (called an Exception Plan), or again prematurely close the project.

Once approved, new Tolerances are set and the project proceeds under the new plan.

Final Thoughts.

Unfortunately, upper management within the project organization, are often suspicious that the project manager may use Tolerance as ‘code’ for padding – and as a safety net for poor estimates and re-work. But they have missed the point. It is there to give the PM enough authority to carry out their responsibilities.

So the tendency to start with, is the Project Board set VERY tight tolerances – with the consequence of the project manager forever raising Exception Reports to bring small deviations to their attention.

Experienced Project Boards (in particular the Executive), will know that Tolerance should be tied back and based on the Business Case. The Executive should ask themselves “what level of Tolerance can I TOLERATE before being bought into the loop and will this level of Tolerance deviation still keep the Business Case VIABLE”.

Remember also, that a Business case should be 'viable' (the cost and risks are worth the benefits?), 'desirable' (should we/must we do this?), and 'achievable' (can we do this?)

Creating and agreeing the REQUIREMENTS for a project are only part of the story
 
It’s equally important to agree what the BOUNDARIES are of any undertaking and these must show what the project is NOT going to do.
 
These elements are bound together and are called the Project Scope Statement which details the project objectives, end-products (deliverables), and requirements. The Scope must be agreed with all concerned, and used to create the project plan ‘baseline’. Once agreed, the scope sets the expectations of all stakeholders so they are clear about what they are going to get when the project is finished.
 
The last thing we want is a disagreement at project handover about what we have or haven’t done – and what was expected.
 
I have found that many projects fail - not because Requirements were not met - but because of difference of opinion about what the project was to deliver.
 
Most projects are triggered by some form of requirements document. These are central to success and lead to the project developing some form of functional specification against which the project outcome is designed. But in my experience, not enough effort is spent getting a joint agreement on these documents, and that is where a scope planning and scope development play a key part.
 
It is also important to recognize the need to have "living documents". The complex relationships between the Requirements, Specification, Design, Development, Business Case, Project Plan, and the risk/Issue/Change Logs prove that ALL documents should be reviewed and refined on a continuous basis during the project. Not because you want to - but because you MUST!
 
"Scope creep" is seen as an industry-wide evil, instead as being viewed as the natural corollary to change control.
 
There is a little-known technique that beats all others hands-down for laser-focussed scope planning and development.
 
It's this. At the very beginning of project planning, agree what the end-product along with the major products are to be. This is best defined by using the Product Description Technique, and only then determine the tasks and resources.  I describe this in detail within my Project Management Training Toolkit ( click here  )
 
Okay? Now let’s run through the key areas in turn of what should be included in the Scope Statement:
 

1. Project Objectives – what the project is to do. These should be quantified and measurements agreed. Typically the measurements will include one or more of, cost, timescale, quality, or business benefits. You will have heard of the SMART acronym for each objective: Specific, Measurable, Accurate, Realistic and tangible, Time bound (time frame plus date).
2. Deliverables (end-Products). Each should have a Product Description written. This contains descriptions of the purpose, composition, derivation, and the quality criteria for it to be acceptable to the customer.
3. Requirements. This is a specific skill, almost certainly done by specialist team, the customer, users, etc. But it is the responsibility of the project manager to make sure they are captured and agreed. Requirements quantify and prioritize the wants, needs and expectations. They may also describe some aspects of functionality of the project deliverables.
4. Project Boundaries. Care must be taken here. This should focus on what is to be excluded from the scope in terms of requirements, objectives, and deliverables. It’s a good idea to create a draft boundary document and circulate it for comments. Or perhaps generate the document from within a meeting with key stakeholders.
5. Product Acceptance Criteria. This should document the WHAT and the HOW that will be carried out as part of agreeing successful project closure. It must be the Customer/Users perspective. The actual criteria used can be taken from a wide choice of aspects, and may include elements such as ease of use, reliability, operating costs, performance data, etc. This should also include HOW the objectives, deliverables and other outcomes of the project are to be approved.
6. Constraints. All projects have constraints – often put there by humans – sometimes by the rules of physics! A constraint is anything which impedes the project team s work. The obvious choices may include, time, cost, quality, key milestone dates or logistics, standards, procedures, directives, compliance, legal and law, health and safety, technology, etc. Whatever. Get them down and agreed – then plan accordingly.
7. Assumptions. In a nutshell, anything you believe to be true. Do not use this section to capture a load of disguised risks (although stated assumptions may lead to generated risks). Documenting them at the start of a project helps test these assumptions and get them agreed. Should these assumptions prove to be false at a later date, these captured statements can be used as a basis to plan and manage the way forward.
8. Project Organisation. Well, as it is initially – it is likely that changes may be necessary to the roles and responsibilities assigned to individuals.
9. Initial Risks. Any known risks at this time. It is helpful to include an initial risk analysis so that readers can get a ‘feel’ for each risk.
10. Milestones. These may be externally dictated and/or internally created as a result of planning by the project manager. Be sure to have them represent significant points of achievement (or key decision points such as an end-stage assessment).
11. Funding Limitations. This is different to cost constraints. It refers to the availability of money to finance the project, and this may have an impact on cash flow. It may state key dates when funds are available, these may be dictated by certain completion criteria, and it also state the amount of funds released at a given point.
12. End Product Description. This should include the quality criteria for the product to be acceptable for the customer/user.
13. Specification Document. This is usually derived directly from the Requirements document. It is usually highly detailed and created by the specialist team along with input from the customer and users.

Final thoughts.
 
Okay, it’s quite a list. Getting the scope correctly and accurately documented is a tremendous aid to ensuring a successful project.
 
But let’s consider a small to medium complex/risk type of project. ALL of the above could be driven as an interactive meeting agenda. The project manager could manage the meeting (don’t forget to invite all interested parties), and capture the agreements.

An hour or so later the PM could e-mail all attendees a neat documented scope statement for their final comments and sign-off.

Project managers are there to plan and manage the work – NOT to do it!

As a PM you will need to be a Leader And A Manager: Leaders share and communicate a common vision (of some future state); they gain agreement and establish the forward direction. They motivate others. Managers are results driven and focus on getting work done against agreed requirements. A good project manager will constantly switch from a leader to a manager as situations require.

As a PM you will need to be a Team Builder And A Team Leader: Because projects are often cross-functional in that they use people who may not have worked together before. It is up to the project manager to set the ‘tone’ of the team, and to lead them through the various team development phases to the point where they perform as a team. Often, the team individuals have their own line manager, and so the PM has no implied authority – yet still needs to motivate the individual. This is particularly true in a ‘Matrix’ organisation.

As a PM you will need to be a be A Problem Solver: This is a skill that can be learned – it just needs a little ‘detective’ work up-front! You will want to first identify the possible ‘causes’ that lead to the problem ‘symptom’. Now, causes can come from a variety of sources, some are:

• interpersonal problems
• internal sources
• external sources
• technical sources
• management sources
• communication
• opinions or perceptions

and so on. The next step having found the root causes is to analyze possible options and alternatives, and determine the best course of action to take. Take care to agree what ‘best’ really means here!

As a PM you will need to be a Negotiator and Influencer: Negotiation is working together with other people with the intention of coming to a joint agreement. It doesn’t have to be the eye-ball-to-eye-ball power struggle you may be thinking of! For example getting one of the team to work late to meet a deadline when they would prefer to go to the Ball Game. For all these you need to have some influencing skills. Influencing is getting events to happen by convincing the other person that your way is the better way – even if it’s not what they want. Influencing power is the ability to get people to do things they would not do otherwise.

As a PM you will need to be an Excellent Communicator: Being a communicator means recognising that it’s a two-way street. Information comes into the project and information goes out of the project. A good way of summarising this is that all communications on your project should be clear and complete. As a project manager you will have to deal with both written and oral communications. Some examples are documents, meetings, reviews, reports, and assessments. A good mental guideline is “who needs this information, who gathers and delivers it, when or how often do they need it, and in what form will I give it to them”

As a PM you will need to be a Good Organizer: Let’s just think of the aspects you will need to organize; project filing including all documentation, contracts, e-mails, memo’s, reviews, meetings, specialist documents, requirements and specifications, reports, changes, issues, risks, etc.

It’s almost impossible to stay organized without having Time Management Skills – so add this to your list!

As a PM you will need to be a Competent And Consistent Planner: The skill of planning can’t be underestimated (and neither can estimating!). There are known and logical steps in creating plans. As a project manager you will certainly own the Project Plan – but there may be others depending upon the project. Examples are, Stage Plans, Exception Plans, Team Plans, Hand-over Plans, Benefit Realisation Plans, etc.

Don’t worry if you haven’t heard of some of these as they may not be necessary – just be aware that planning should become second nature to you.

Two aspects need to be mentioned here:

• Plans are ALWAYS documents – don’t fall into the trap of thinking that, for example, a Gantt Chart is a plan – its only a schedule diagram.
• Successful projects are delivered by successful teams. ALWAYS use the team to help create the Plan (unless, rarely, there is a good reason why not, such as commercial confidentiality, or contractual conditions)

As a PM you will need to Establish And Manage Budgets: At the heart of this is the skill of estimating – particularly cost estimates. Nearly always the project manager will need certain knowledge of financial techniques and systems along with accounting principles.

Part of the Project Plan will be something called the Spend Plan. This will show the planned spend against a time-scale. The PM will want to get involved in purchasing, quoting, reconciling invoices, time sheets, labor costs, etc.

The project manager then needs to establish what has actually happened as opposed to what was planned and to forecast the expected final costs. Normally accounting and project management tools will help – but remember the garbage in = garbage out rule!

Well, that just about summarises the main areas. If you are new to project management, don’t be too bamboozled by all this – there are well understood methodologies, tools, guidelines, and procedures to help you on your way to developing the important life-skill of Project Management.

Here are the most important skills in detail, that the project manager MUST have:

Communication skills

• These should be both written and oral.
• The project managers communication skills will be summarise in the communication plan:
• Who are the stakeholders both internal and external?
• what are their major interest areas with the project and its outcome?
• what information will be of most interest to each of them?
• Who, and how, will that information be gathered?
• Who will give the information to the Stakeholders?
• When do they want the information, or how often?
• How will the information be given to them?

The project manager should ensure that both information coming out from the project, and information coming back into the project is covered in the above plan.

Organizational and planning skills

There is much organising to do within a project. These will include:

• Organising meetings
• Assembling teams
• Public relations
• Project documentation
• Project reports
• Project registers and logs
• Quotes and contracts
• Meetings
• Requirements, specifications, and project Scope
• Develop schedules

the list is endless...

Organising also needs excellent time management skills.It goes without saying, that planning skills are vital.

Budgeting skills

The project manager will need some knowledge of accounting and finance principles. Of particular interest is budgeting and cost control. These will include estimating skills.Budgeting and contracts will need to be understood by the project manager to remain in control.

Conflict management skills

All projects will have risks, issues, and conflicts. For this reason, problem-solving skills are vital.The project manager will want to develop a structured method for problem resolution.As each new problem arises, the project manager will want to define it accurately, and perform and impact analysis, before determining the correct type of action.

The project manager will also be responsible for either implementing the actions themselves, or escalating the problem is required. All actions should be implemented in a timely manner.

Negotiation and influencing skills

Some people are natural negotiators while others are not. However it can be learned. Negotiation put simply, is getting two sides, with different needs, to come to an agreement. Good negotiation will result in both side's being satisfied by the outcome -- probably with some compromise.

Negotiation will be a continuous activity from the beginning to the end of the project.

Being able to influence others is another key skill: Influencing is the ability to get others to do what you want, even when they have a different opinion. There are two key parts of this:

Politics. This involves getting people with different goals and interests to cooperate

Power. This is the ability to get people to do things they wouldn't do otherwise, by getting them to change their minds.

Leadership skills

Managers concentrate on results and getting the job done, whereas leaders have a vision of a future state, gain agreement, inspire, and motivate others.

Teambuilding and motivating skills

The project manager will often needs to lead teams who have a different line manager, and come from different parts of the organisation. The teams may not have worked together before, and the negotiating and influencing skills mentioned before, will be needed to form the team, and develop them into an effective unit.

The Project Management Plan establishes project management's interpretation of the why, what, how, who, how much, and when of the project. It's the Bible, Quran, Tanakh (select your religious text of choice) for all aspects of the project.

It is a baseline tool used as a reference for managing the project. It is one of the most important document in the overall planning, monitoring, and implementation of a project and is owned by the project manager and his/her team. The plan should include: A definition of overall objectives, statements on how these should be achieved (and verified) Estimates of the time required. This defines how the project executed, how it is monitored and controlled, and how it is shutdown in a controlled manner.

The project management plan should include the following aspects:

• Project processes
• how the processes will be executed
• tools and techniques to be used
• essential inputs and outputs and how they will be used to manage the project
• dependencies and interaction of the processes used to manage the project
• methods for executing the work to fulfil the objectives
• methods for monitoring and controlling changes
• methods to perform configuration management
• methods for determining and maintaining the validity of performance baselines
• communication needs of the stakeholders and how those needs will be fulfilled
• project life cycle
• project phrases for multiphase project
• management reviews of issues and spending decisions

There will be many subsidiary plans, which may remain separate, for small project may be combined into one document.

According to the MPBOK, these are the subsidiary plans:

• Project Scope management plan
• scheduling management plan
• cost management plan
• quality management plan
• process improvement plan
• starffing management plan
• Communications management plan
• risk management plan
• procurement management plan

When developing the subsidiary plans, there are components of each of the processes that should be considered. These are as follows:

• Milestone list
• resource calendar
• schedule Baseline
• cost Baseline
• quality Baseline
• risk register

Remember. All plans are subject to changes, and the above list will need to be referenced on a regular basis and updated as required.

Senior management will be required to approve these changes.

The project management Institute (PMI), is one of the largest project management organisations in the world. They sponsor the PMP exam which is fast becoming the worldwide standard for project management skills.

One of the most valued credentials in project management, the PMP credential assures employers that you are committed to project management. Earning and maintaining this credential demonstrates a solid foundation of experience in effectively managing projects. PMI was founded in 1969, was first examined in 1984 and now has over 150,000 members worldwide.

There are many reasons why you should become PMP certified:

• it demonstrates proof of your professional achievement
• it gives you many more career opportunities in your particular field or industry
• it increases your marketability
• it increases customer confidence in you and your organisation

There are many training organisations both offline and online who offer accredited courses leading to your PMP certification.

If your thinking of sitting the exam then bear in mind that you must have had several years of experience as a project manager, including 35 hours of formal project management education, before you can sit the 4 hour exam (The exam consists of 200 randomly generated questions, but only 175 of the questions are scored. To pass, you need 141 correct answers)

Candidates for the PMP credential:

• Perform their duties under general supervision and are responsible for all aspects of the project for the life of the project.
• Lead and direct cross-functional teams to deliver projects within the constraints of schedule, budget and resources.
• Demonstrate sufficient knowledge and experience to appropriately apply a methodology to projects that have reasonably well-defined project requirements and deliverables.

PMI offers a comprehensive certification program for professionals with varying levels of experience that supports a career framework. There are six main process groups and areas:

• Initiating
• Planning
• Executing
• Monitoring and controlling
• Closing
• Professional responsibility

To achieve PMP certification, each candidate must satisfy all educational and experiential requirements established by PMI, agree to adhere to a code of professional conduct, and must demonstrate an acceptable and valid level of understanding and knowledge of project management. The PMP certification examination tests this knowledge. PMP-certified professionals must also demonstrate ongoing professional commitment to the project management field by satisfying PMI continuing certification requirements program.

Tips on taking the PMP exam

The PMP certification examination is a computer-based exam based on information from the entire project management body of knowledge. The “Guide to the Project Management Body of Knowledge” (PMBOK), which is published by PMI, provides an outline of the topics covered.

The four-hour exam consists of 200 multiple choice questions with four possible answers (a through d). The participant needs to correctly answer 137 of the questions (68.5%) to receive a passing grade. Because the exam is computer based, participants can find out how they scored by reading the detailed report on performance that is available when the exam is completed.

PRINCE stands for PROjects IN Controlled Environments.

Prince2 is a structured method for effective project management. It is a process-based approach for project management providing an easily tailored and scalable method the management of all types of projects. The method is the de-facto standard for project management in the UK and is practiced worldwide.

A Potted History of Prince

The method was established by the central computer and telecommunications agency in 1989, originally developed from a project management method created by Simpact Systems in 1975 this was originally known as PROMPTII. Four years later in 1979 it was adopted by the CCTA (know known as the Office of Government Commerce) as the standard used for all government information projects.

What is PRINCE2?

Before we go into the specifics of PRINCE2, there are some general points about the subject of project management, which should help put everything into context...

Why project management is important

Whenever we decide we want to do something, go somewhere, build something, achieve something, we need to know the answer to some questions. What are we trying to do? When will we start? What do we need? Can we do it alone, or do we need help? How long will it take? How much will it cost? These are typical questions asked at the start of any project and the answers are the building blocks of project management - defining what we want to do and working out the best way we can do it.

Structured project management means managing the project in a logical, organised way, following defined steps. A structured project management method is the written description of this logical, organized approach. PRINCE2 is a structured project management method.

We have briefly covered what structured project management, and hence PRINCE2, are all about. Now for some more details about the PRINCE2 method.

Coverage of PRINCE2
PRINCE2 says that a project should have:

• An organized and controlled start, ie organize and plan things properly before leaping in.
• An organized and controlled middle, ie when the project has started, make sure it continues to be organized and controlled.
• An organized and controlled end, ie when you've got what you want and the project has finished, tidy up the loose ends.

In order to describe what a project should do when, PRINCE2 has a series of processes which cover all the activities needed on a project from starting up to closing down.

Organizing and controlling a project means that we need to have someone responsible for doing the organizing and controlling - this person is called the Project Manager. The Project Manager will select people to do the work on the project and will be responsible for making sure the work is done properly and on-time. The Project Manager draws up the Project Plans that describe what the project team will actually be doing and when they expect to finish.

The person who is paying for the project is called the customer or executive. The person who is going to use the results or outcome of the project, or who will be impacted by the outcome of a project, is called the user. On some projects, the customer and user may be the same person. The person who provides the expertise to do the actual work on the project (ie will be designing and building the outcome) is called the supplier or specialist. All of these people need to be organized and co-ordinated so that the project delivers the required outcome within budget, on time and to the appropriate quality.

Each PRINCE2 project will have a Project Board made up of the customer (or executive), someone who can represent the user side and someone to represent the supplier or specialist input. In PRINCE2, these people are called Customer, Senior User and Senior Supplier respectively. The Project Manager reports regularly to the Project Board, keeping them informed of progress and highlighting any problems he/she can foresee. The Project Board is responsible for providing the Project Manager with the necessary decisions for the project to proceed and to overcome any problems.

Providing an independent view of how the project is progressing is the job of Project Assurance. In PRINCE2, there are three views of assurance; business, user and specialist. Each view reflects the interests of the three Project Board members. Assurance is about checking that the project remains viable in terms of costs and benefits (business assurance), checking that the users' requirements are being met (user assurance), and that the project is delivering a suitable solution (specialist or technical assurance). On some projects, the assurance is done by a separate team of people called the Project Assurance Team, but the assurance job can be done by the individual members of the Project Board themselves.

On most projects there is a lot of administrative work needed, keeping everyone informed, arranging meetings, keeping plans up-to-date, chasing things up, keeping files, etc. Project Managers often do all this work themselves, particularly on smaller projects. But if there are a number of projects going on at the same time, a Project Support Office can be setup to help the Project Managers with this work.

Apart from describing the different people involved on a PRINCE2 project, and what they are each responsible for, the method also explains how to manage risk, how to manage quality, and how to control change on the project. Risk Management is about working out what could go wrong and planning what to do if it does. Quality Management is about checking the quality of work done on the project, either by testing it or reviewing the work in some way. There are always lots of changes during the life of a project; people change their minds, other things happen, which affect what the project is doing. PRINCE2 has a technique of controlling the way changes impact the project in order to prevent the project going off in the wrong direction.

So, PRINCE2 is a method for managing projects. It helps you work out who should be involved and what they will be responsible for. It gives you a set of processes to work through and explains what information you should be gathering along the way. But PRINCE2 doesn't do the work for you, it cannot guarantee that your projects will be successful. Good projects, which deliver quality results, on-time and within budget are dependent on the quality of people involved from Project Board down to individual team members.

And finally
Having read this brief introduction to project management and PRINCE2, the next thing to do is go on a training course and find out more! Please have a look at the PRINCE2 ATO Listing for more details of training providers, or if you would rather sit the examination after self-study, go to Open Centre Examinations.

For more detailed information about risk assessment and management, visit the Project Management Institute's Web site at www.pmi.org and review their PMBOK Guide.

www.DAVELITTEN.com

Learn Project Management and Life skills from the best!

Dave Litten is one of the UK's best known Prince2 accredited trainers: His resume is longer than my arm and he has run more projects than I've had hot dinners. Dave now spends his time teaching Project Management skills to Project Managers.

He is now in semi-retirement and splits his time between flying all over Europe running Prince2 Training courses and working from his Spanish Villa publishing Project Management and Life Skills articles on his website.

Dave's website opened it's doors in July 2007 and as Dave says "it's aimed at being a daily dose of rational thought and mental lessons from my professional and personal life with sections on different topics. If anything on this website is useful to you - Fantastic! Because that's the whole point of it!"