Jun 082011

Managing complex projects in any industry is tough. Achieving success in long-term projects is even tougher. But why is project management such a difficult thing to get right?

Many complex, long-term projects fail to live up to their promises and produce disappointing outcomes on completion. Some of these are well-known for exceeding their budgets or deadlines or both. Take London’s 2012 Olympics Project whose budget of over £9bn is triple the original estimate and whose contingency fund of nearly £3bn was almost entirely earmarked for certain tasks by as early as the first quarter of 2010, over 2 years before the deadline.

APM Project Management covers all the key areas of project management

Not all projects are such high profile ones but there are plenty that exceed their budgets or fail to deliver on their promises just as spectacularly. Project managers often have a poor reputation for delivering what was expected without budget or time over-runs. And one of the industries with the worst record is the technology industry where failures are said to exceed 50% of all projects undertaken.

So organisations make commitments to major projects but cannot always deliver what was expected and, more worryingly, cannot determine how much value they are getting from their investment. Many corporations do not even measure the value added by a project once it has been completed.

Publicly available statistics of project failures vary dramatically in their estimates and do not include confidential data from private corporations so are not an entirely reliable guide. Yet each new project begins with enthusiasm and no expectation of failure but often without having learned lessons from previous projects that might contribute to success this time around.
Even on simple, straightforward projects there are many areas that can cause the sorts of problems that can eventually manifest themselves in failure. Add to the many possible causes of failure any level of complexity and problems can rapidly escalate into disasters. Here are just some of the most common causes of project failure:

1. Poorly defined Project Scope
2. Inadequate Risk Management
3. Failure to identify key assumptions
4. Project managers who lack experience and training
5. No use of formal methods and strategies
6. Lack of effective communication at all levels
7. Key staff leaving the project and/or company
8. Poor management of expectations
9. Ineffective leadership
10. Lack of detailed documentation
11. Failure to track requirements
12. Failure to track progress
13. Lack of detail in the project plans
14. Inaccurate time and effort estimates
15. Cultural differences in global projects

So the causes of project failure are wide and varied. In addition promised resources may not be available when required, executives may fail to grasp the full reasons behind instigating a project or there may be political reasons for continuing with a clearly unviable project.

But how can lessons be learnt from previous project failures?

Of all the different causes of project failure there are 3 that are by far the most important and, if dealt with comprehensively, can be effective in avoiding project failures. These areas are the Scope, Risks and Assumptions. Also important is maintaining the existing skills base within the team and developing new or inexperienced employees through project management training. Professional project management courses in methodologies such as PMP, APMP or PRINCE2 can assist in developing and retaining talented project managers and team members.

Apr 122011

Private companies and government organisations involved in running large projects, or many smaller projects at the same time, already recognise the benefits of formal project management and relevant training for those involved in projects. Whether that’s the APM Project Fundamentals Qualification for those new to project management or more advanced accreditation such as the APM RPP (Registered Project Professional) training in formal methods is essential for project success. However, as the amount of experience and knowledge gleaned from such tasks has increased so project management has become more complex. And as it has become more complex so the tools and methodologies have had to evolve to keep pace.

It was the UK governmental body OGC (Office of Government Commerce) that back in 1989 first defined the structured methodology that has evolved today into the internationally recognised PRINCE2 methodology. It was originally established to help Government departments deliver the best value possible from its capital expenditure and is an acronym for Projects In a Controlled Environment. Of course, there are also other knowledge-based methods from APM (Association for Project Management) and PMI (Project Management Institute).

Formal methodologies are commonly used for software development, manufacturing, engineering, and construction projects to plan, schedule and control all of the tasks and activities required. More and more they are also being used by services and solutions companies in order to add discipline and control to their projects.

Consequently, managing projects is now a fundamental part of many businesses and the role of project manager is now a professionally recognised one, which involves not only planning, scheduling and controlling activities but also expertise in identifying and managing risks, change and quality. The skills required to successfully complete projects are very much in demand in the competitive business environment and include not only a technical ability to efficiently manage tasks but also people management skills and good business awareness.

An internationally recognised qualification can be a real advantage but equally important are other skills such as:

• An open-minded attitude to each new task
• The ability to select the right software tools
• Understanding the business case
• Describing the business goal that the project is striving for
• An ability to tailor methods and techniques to particular projects
• Effective prioritisation of every part of the project
• Negotiating skills for requesting additional resources
• Learning lessons from previous projects to avoid repeating mistakes
• Questioning all assumptions made
• Diplomatic skills to gain support where required

Of course, all of these skills will only benefit a project manager with a good, sound understanding of professional methods and techniques.

It is essential to create a written document that clearly states the scope of the project. This might be known as the Scope Document, the Project Charter or the Business Requirements Document. Whatever it is called in your organisation the key factor is that the scope of the project, what is included and what is specifically excluded, is clearly and unambiguously documented and that it is approved by all of the stakeholders to the project.

This document will prove invaluable later on in the project when issues are bound to arise over what exactly should be delivered and where certain responsibilities lie. It will also help with assessing how realistic initial schedules and budgets are. A scope document should include a breakdown of the different tasks required to complete the project and an assessment of the likely benefits versus the costs in a cost-benefit analysis.

It is also essential to ensure that there is a communication plan in place so that all stakeholders, managers, team members and anyone else with an involvement in the project are kept fully aware of the progress of the project. Communicating is a two-way thing so the plan should allow for feedback and, more importantly, all feedback received should be assessed. Ignoring the concerns of anyone involved in the project, no matter how junior they might be, runs the potential risk of failing to deliver the project on-time and on-budget. By communicating effectively, vital commitment and cooperation will be gained from the team, and support from those who are affected but maybe not involved to any great extent. A lack of communication only serves to raise objections and generate resistance to a new project.

And while all this is going on a professional project manager will not forget to motivate and encourage the project team, to repeatedly monitor progress and adjust the project plans, where necessary, and to manage all the potential risks within the project. After all project management is simply about getting things done whether you choose to follow a PRINCE2, PMP or APMP methodology.

Mar 082011

A Business Requirements Document is a formal document that effectively provides a contract between a “supplier” and a “client”. The “client” is typically a business department and the “supplier” is the company or other business department that will create and deliver the new product, system or process. The document describes in detail every business need and is written in response to a known business problem or shortcoming. The Business Requirements Document is not expected to describe in detail the solution to the business needs but to describe what the business wants and needs. For technical products, such as new or modified software systems, further technical specifications will be prepared.

Various techniques, such as brainstorming, story boarding, use cases and interviews, will have been used to gather the requirements during a business requirements analysis process. That information needs to be written down in a clear, concise format in language familiar to the business users. The process of documenting and refining the business requirements helps to identify conflicting requirements and potential issues early on in the project lifecycle. It is the key document in the effective project management of any type of project.

The business requirements document effectively defines the Scope of a project. This is the description of what will be included in the project and also what is specifically excluded from the project.

Scope is a definition of the limits or boundaries of a project and the reason it is so important is because poor management of the project scope is one of the major causes of project failure. Good management of the project scope by the project manager involves 3 key factors:

  • devote adequate time to fully defining the requirements
  • reach a formal agreement on the scope with the stakeholders
  • avoid scope creep

Scope Creep

Scope creep is when un-authorised or un-budgeted tasks lead to uncontrolled alterations to the documented requirements during the course of the project. The business requirements document should address the possibility of requests for additional tasks in a project and state how they will be dealt with. This usually involves a formal Change Request Procedure that requires the agreement of all stakeholders to any changes of specification, budget or delivery time. The fact that the business requirements document is a formally approved document assists the project manager in implementing and sticking to a Change Request Procedure.


There is, of course, a tendency for changes to be requested during the life of a project. As projects progress, the end-users inevitably see areas where additional features could provide increased benefits. And the purpose of scope management is not to prevent such changes either being requested or implemented, but to ensure that all changes bring substantial, well-defined benefits. And that the budget will be increased accordingly and that the extended duration of the project is acceptable to all parties involved. Failure on the part of the project manager to manage scope adequately undermines the viability of the whole project as approved in the Business Requirements Document.

All changes to the requirements, budget and schedule must be approved by all stakeholders. In large projects it is common for end-users to see their opportunity to have all the “nice-to-have” elements added while major changes are underway – to some extent this is understandable but only if the new features add real business value such as efficiency or accountability and do not require the project to change in such a way as to lose sight of the original business needs that instigated the project in the first place.

Document Iterations

A business requirements document is likely to need several iterations before it is close to reaching a document acceptable to all stakeholders. Writing such a document can be a complex and intricate process and will probably need many more iterations before approval is actually achieved. This is no reflection on the thoroughness of the analysis process but rather on the simple human difficulty in translating thoughts and speech into clear, unambiguous and thorough wording on the page. Whilst adequate detail is required to fully define the requirements, conversely, too much detail prevents the readers from absorbing the key points. Writing a document that achieves this balance is a skill in itself.

Fortunately, there are a number of best practice approaches and industry standards that can be used to good effect when writing a business requirements document. These will assist in defining the project scope and managing scope creep once the project is underway.

Key Document Elements

Whether the author of the business requirements is the business analyst or the project manager, they should have an understanding of the different levels of requirements and the different elements within the requirements. They must be able to state the business needs clearly, understand the current business process and the key business objectives driving the project.

The following list, whilst not exhaustive, covers the main areas that should be documented in a business requirements document:

  • Business Problem Statement
  • Current Business Process
  • Scope Statement(s)
  • Key Business Objectives
  • Project Completion Criteria
  • Limitations
  • Risks
  • Assumptions
  • Functional Requirements
  • Non-Functional Requirements
  • Features and Functions
  • Reporting Requirements
  • Delivery Method
  • New/Modified Business Process
  • Data Retention/Archiving
  • Training
  • Stakeholder List
  • Quality Measures
  • Checklists (Process and Requirements)


Ensuring each of these elements is incorporated in to the document with sufficient detail and clarity is the first step to creating a perfect business requirements document. Techniques for writing effective business requirements are covered on both general project management courses and on specific courses for APMP, PRINCE2 and PMP.

Mar 082011

Podcasting is one of the most exciting new forms of communicating to an audience to have emerged in recent years. Many types of businesses as well as the government and people in education have started to discover the advantages of delivering their messages to their listeners at a time and in a place that suits them.

Any time of the day or night and, literally, wherever you like – at home, travelling or even whilst on holiday – listening to podcasts is the most current way to keep up with the latest news, your favourite radio program or, more usefully, complete that training course you have been meaning to get around to sometime soon. You can learn at a pace that suits you and can listen to a topic again and again as many times as you wish.

Podcasts are audio (mp3) files made available over the internet but more importantly subscribers to a particular podcast are notified when the latest topic becomes available and it will be automatically downloaded.

Although many people use an iPod to listen to a podcast and the origins of the podcast name is associated with Apple’s ubiquitous mp3 player (and, of course, the word broadcasting) you can, in fact, use any mp3 player or, indeed listen to the podcast through a computer or laptop or even your phone.

Of course, with respect to training courses it is perfectly possible for study guides and course manuals to be emailed to those signed up for the course for remote independent study. Or the same information can be made available on the training company’s website but podcasts simplify access to learning.

No computer or internet connection is required (once the initial download is done) and additional emails do not clutter up already overloaded inboxes. Instead those people subscribed to a course become part of a community who are automatically notified of each new topic as it becomes available.

In education and training, podcasts are an extremely effective way of demonstrating passion and conviction on a certain subject, because verbal communication can provide emphasis in a way that the written word cannot. It is also easier to reinforce important aspects of a subject through the more informal verbal style of communicating typically used in podcasts compared to other forms of distance learning and e-learning.

So a verbal form of providing a training course can in many ways be more beneficial than written guides and can be especially appealing to some people. Many people actually learn better when they hear a subject than when they read it in a book.

Although the term podcasting comes in part from the word broadcasting, it is technically a form of what is called narrowcasting because the listeners have subscribed to the podcast. The communication is to a small niche community whose requirements are known, rather than to a broad audience such as in the broadcast of a radio program.

So for all those busy professionals whose schedules make it difficult to find time to attend a classroom-based course, podcasts are the route to stimulating new learning and ideas in your chosen field, to enhancing your professional skills and improving your career prospects with professional training qualifications.

They are in inexpensive alternative to traditional training courses and mean that organisations without a large training budget can still motivate and retain staff by giving them the opportunity to develop in their career.

Some of the best podcast training courses use 2 instructors presenting the course to ensure there is a natural flow of dialogue that retains the students’ interest. They also provide study guides with each topic containing additional material and exercises to be completed to reinforce the subject being learnt. An online community is almost always established where issues and problems can be discussed with expert course tutors and with other like-minded course participants.

Studying for a business qualification using podcasts is becoming increasingly popular. This attractive, inexpensive alternative to traditional classroom courses is a great use of limited spare time. You can study at your own pace, walking in the countryside or lying on the beach, and it will increase your motivation and improve your career prospects.

Podcast training courses are available for a huge range of subjects from modern languages, accountancy, continuing professional development for lawyers, project management courses and a wide range of other business skills courses.

Listen to this project management training podcast for a taste of what they are like.



Mar 082011

Every project needs a business requirements specification document because it is the formal agreement between the client/end-users, the business owner/stakeholder and the project manager. It states exactly what will and will not be included in a project and what the end-user can expect once the project is completed. This is true for projects that are an extension of an existing status quo, such as enhancements to a software system, just as much as to projects involving brand new scenarios such as the development of new corporate policies.

Fully analysing your business requirements before embarking on a new project will lead, not only, to improvements but to a transformation of the business. So instead of ending up with a new business process, policy or system you could actually enable a substantial change in the business.

All new projects in the workplace are instigated in response to a business need or a business failing. Huge amounts of time and resources are usually expended to fulfil the business need but there is often a mismatch between what is delivered and what was actually needed. A thorough business requirements analysis can help to avoid this scenario by defining and clearly documenting the requirements for a specific business objective. It is the process that enables a clear and precise definition of the scope of a project and by breaking down the business needs into specific tasks it helps to assess the resources needed to complete the project.

Gathering Requirements

What are the best ways of getting started on the analysis process? Fortunately there are some well-recognised techniques for gathering the information needed in a Business Requirements Document. This list is not exhaustive but gives an overview of possible methods to use.

In all of these methods of gathering information, it is important to recognise that individuals from different business areas will only view the project from their own perspective and may not see the bigger picture. The analysis is intended to understand the different perspectives and document exactly what the project should achieve.


Brainstorming is one of the best ways to produce lots of ideas on a particular topic in a short space of time. Set aside an hour in a relaxed environment with no distractions and invite people from all areas involved in the project. But keep the group to no more than 12 people for it to be most focussed and most effective.

The business analyst should encourage participation and a flow of ideas, which are written down on a whiteboard, flipchart, post-it notes etc. When there are plenty of thoughts, ideas and suggestions written down, the analyst then helps to determine which ideas are likely to provide the best solution and, therefore, require further discussion.


Business Analysts use storyboarding to break down a project into small elements in order to focus on one element at a time. This helps to easily identify where information is lacking and where further analysis is required. It also helps in organising the work and communicating in unambiguous language to the end-users.


Interviewing key personnel involved in the project is an extremely effective way of eliciting relevant information but it is important to interview the right people and also to make sure the interview questions stay focussed on the topic in question.

So before embarking on an analysis interview the questions should be prepared to ensure they are open questions (i.e. ones that require more than a one-word or brief answer) and that they cover the key points of: Function, Features, Preferences and User Expertise.


It is often difficult for people to visualise a product, process or system when it is completely new. So for projects which are not an extension of improvements of something that already exists, it is useful to produce a mock-up or model of the product or system to help end-users or clients to visualise what the final product will look like. Prototypes can help to identify inconsistencies, potential problems and usability issues.

Prototypes are most effective once some or all of the other techniques have been used to gather a full idea of the business requirements.

Interpreting the Requirements

Once all the requirements have been gathered and are documented at a high-level of detail it is necessary to determine which requirements can actually be delivered and which requirements are unnecessary to the fulfilment of the business objectives.

Some requirements are more important than others so they must all be prioritised to identify those which are fundamental to delivering a product, system or service and those which are “nice-to-have”.

It is also vital to assess the impact that the new project will have for existing processes and staffing skills and levels. For example, will members of staff need to be re-trained or will some roles become redundant?


Documenting the Detailed Requirements

Requirements must always be written down in language that is easy to understand, precise and unambiguous. Use simple language wherever possible, particularly if the document is not written in the first language of any of those who will be reviewing it. Avoid technical jargon whenever possible, but where it is necessary, clearly state exactly what a term means.

The document must contain sufficient detail that the new product, process or service can be created, tested and ultimately become a “live” product.

All of the requirements must be measurable or quantifiable and it must be possible to test the new product to verify that it meets the business objectives. Every individual task in the requirements document must contribute, even if indirectly, to the end result.

This check-list covers the basics of a Business Requirements Document but writing effective requirements using industry standards and best practices is a topic in its own right that is covered in detail on most project management courses:

  • Clear, unambiguous wording
  • Sufficiently detailed to create the product/process
  • Test cases and conditions can be easily defined
  • It is possible to achieve the desired final product/process
  • Design independent
  • Each requirement can be tracked in the final product/process
  • Every requirement is necessary to satisfy the business objectives.

Agreement and Sign Off

Before embarking in earnest on the project work it is vital that the project manager gets the signed agreement of the business requirements document from the stakeholders. This is their formal commitment that the document accurately and thoroughly describes the business needs.

Business Requirements Analysis is covered in detail on project management courses in all recognised methodologies such as APMP, PRINCE2 and PMP. Professional project management training is a vital element in the success of the analysis and documenting of the project scope in every type of project.