More Blog Posts About Project Management

I have been busy trying to write on various other platforms to avoid putting "all my eggs in one basket". What I hope this will do is give all you project managers out there a better chance of finding my posts (and actually reading them, hopefully).

I qualified as a PRINCE2 practitioner several years ago while working for a blue chip international organisation in London but have used a mixture of what I learnt on my PRINCE2 training courses and the practical experience and skills I gained from many years working on and managing IT projects. Naturally much of how I run my IT projects is based on an agile approach and I am a firm believer that traditional project management methodologies combined with a flexible, agile approach can usually produce the most efficient and successful outcome.

So if you want to read more about what I write on the broad topic of project management take a look at the advice and tips in these posts:

Project Managers - Success is in your Hands

How Project Managers Can Save Time

Some of the Best Practices in Healthcare IT Project Management

A Guide to the APM Project Fundamentals Course

Tips for New Project Managers

Kinja - Five Ways You Could Ruin Your Career in Project Management

Goals, Milestones, Aims and Objectives

In the English language the terms goals, milestones, aims and objectives all mean essentially the same thing and are used interchangeably in business and in everyday life. But frequently in a project management environment they are used to distinguish between long-term and short-term targets. 

On project management courses they often talk about the importance of the business objective in a project and how this is the over-riding factor that should always be our primary concern in every decision-making activity throughout the project. So an objective or aim is clearly the final outcome of the project – it could, for example, be "Implement an online booking and payment system…". It may, or may not, include some type of deadline, for example, "…by the end of 2014".

The business objective or aim represents the ultimate vision of the project sponsor and other stakeholders of what will be achieved when the project is successfully delivered.

Goals and milestones, on the other hand, relate to intermediate targets that can be used to determine whether the project is on track. They can also, sometimes, be points at which to deliver a completed stage or phase of the project. They can represent the completion of a packet of work that can be used independently of the final product and add some business benefit of their own. 

So goals or milestones are short-term achievements of which an example is: “Build an online data repository for client booking details.” Goals are very project-specific and particularly in IT projects their benefit may be less obvious to the end-user - it may be an underlying IT development required for future tasks, such as a library of functions that brings no immediate business benefit.

It may seem a little pedantic to differentiate between these terms in project management, but the distinction is worthwhile to avoid ambiguity. Project management methodologies such as PMP and PRINCE2 place great emphasis on the business objective throughout the life of the project. And perhaps, just as importantly, this distinction provides the project team with a manageable set of targets to achieve in relatively short timeframes. The goals or milestones will motivate the team during the course of the project but the objective or aim will ensure they stay focussed on the end result as the project progresses and the inevitable changes and problems arise.

10 Ways to Motivate your Project Team

I've been reading a lot lately about what motivates a person in a work environment and, more specifically, in a project environment. Motivation is one of those things that is different for different individuals but if you can get it right in your project team then a motivated team can overcome all sorts of problems and issues. In my experience a motivated team will always deliver a project successfully.

And yet, for all the advice available on how to motivate people, somehow many organisations fail to do it well. That's, of course, partly because they don't have the will or the ability to implement changes that might improve motivation.

I used to work with a bunch of high-flying city traders – almost without exception they said that money was the only thing that motivated them. But they were all young and I have to wonder what is the motivation once you have more than enough money. They would probably argue that you can never have enough money but in the real world when you are being paid well to do a job, what then motivates a person week after week, month after month and year after year?

Well, this is my highly distilled list of the top ways to motivate your project team:

1.      Let their voices be heard. Listen to their opinions and concerns and act on them whenever possible. If you don't agree with their opinions then explain why and take their concerns seriously (even if you think they are trivial, they are clearly important to the project team member).

2.      Talk to the team members in person on a regular basis and not just at scheduled meetings or brainstorming sessions. If you are in the same building and can talk face-to-face then don't phone or send an email.

3.      Help each team member to gain new project experience – push them outside their comfort zone a little by giving them additional tasks and responsibilities that will increase their confidence.

4.      Be flexible about when their working day starts and end – recognise that the team members have a life outside work. As long as every team member is in the same location for a core number of hours every day, and that tasks are completed on-time, a little flexibility can make a big difference in motivating a project team.

5.      Encourage the team to work together, to learn from each other and to be a sounding board for bouncing new ideas off each other.

6.      Discourage competitiveness between team members – of course competitiveness between other organisations can be good for motivation, but within the team it will simply lead to a divisive and "me-centred" attitude.

7.      Help each team member to develop professionally by encouraging them to attend professional project management courses. If traditional off-site training is not an option then look into e-learning and podcasts that will enhance their project management skills.

8.      Encourage creativity and innovative thinking by giving the whole team the opportunity to get together for informal sessions that are not concerned solely with the current project. Use it as an opportunity to come up with ideas for the next project.

9.      Don't let a blame culture become established either within the project team or within other departments involved in the project. Encourage acceptance of a problem or mistake and move on to finding ways of resolving it. But don't forget to make sure everyone has learned a lesson for next time.

10.  Buy coffee and doughnuts every once in a while for the whole team. Everyone loves a treat!

Now that I have written that list it doesn't sound too hard to motivate a project team. Just remember the key points are to allow the team to learn and develop professionally in a creative environment. Make sure they have access to the right project management training so they can learn new skills and put them into practise in a project environment.

10 Things Every Project Manager Should Know

GANTT CHART

Gantt charts are the most generally useful tool in project planning. They are used for scheduling and monitoring tasks, for showing costs and expenditure at all stages throughout the project, for communicating progress and producing reports. They show, on a simple block diagram, the activities and costs over time in an easy-to-understand way.  They can be created in a range of software tools or even in a spreadsheet. 

The project is broken down into individual tasks which are listed in rows on the chart. Each task has a timeline extending out to the deadline of the task. Overlaying the timeline is a progress line, showing how much work has been done on the task so far, and also the important milestones along the way. Estimated and actual costs to date can also be added at the end of the timeline.

Because the chart covers the days, weeks and months of the whole project it is simple to track progress of the project provided the chart is updated regularly and accurately.

PROJECT SCOPE

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 is when un-authorised or un-budgeted tasks lead to uncontrolled alterations to the documented requirements during the course of the project.

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.

RISK MANAGEMENT

In order to deliver successful projects that come in on-budget and on-schedule and meet the needs of the business, it is critical to manage the risks inherent in every project effectively. Managing risks within a project involves identifying and analysing the risks then designing a strategy to deal with the risks. No project is ever without risks, but it is the nature and complexity of the project that are likely to determine the impact of the risks on the overall success of the project. 

The main tasks involved in Risk Management are:

·         Identify and analyse the risks.

·         Establishing and maintaining a Risk Log listing the risks and their severity.

·         Analysing the probability of each risk occurring and its impact

·         Developing a strategy for responding to risks that occur

·         Allocating contingency funds and time in the schedule

BUSINESS REQUIREMENTS

Every project needs a business requirements specification document because it is the formal agreement between the client, the business stakeholder and the project manager. It states exactly what will and will not be included in a project and what the client can expect once the project is completed. 

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.

PRINCE2

PRINCE2 is a methodology for managing projects effectively. It stands for Projects In Controlled Environments and is a flexible process with a strong focus on the business justification of a project and an emphasis on dividing the project into small manageable and clearly defined stages.  It also has a defined organisation structure for the project management team.

It is a framework that focuses on the delivery of products rather than carrying out specific tasks and has a finite lifecycle. PRINCE2 is used to ensure the following:

• Effective use of available resources
• Effective management of risks
• Early identification of issues
• Good communication
• Lessons are learned from every project

APMP

APMP is a knowledge based qualification for which a project manager needs to be able to demonstrate knowledge of all aspects of project management and understand how they interact and how a project fits into the strategic and commercial environment. It is an internationally recognised qualification sponsored by the Association for Project Management (APM) aimed at those wishing to achieve a broad level of project management knowledge.

The breadth of knowledge required includes budgeting and cost management, conflict management, communication, earned value management, leadership, negotiation, procurement, sponsorship and teamwork.

PMP

PMP is an internationally recognised project management certification sponsored by the Project Management Institute (PMI). It is designed to objectively assess and measure professional knowledge and candidates must satisfy educational requirements and demonstrate a defined level of experience before embarking on one of these project management courses. To achieve the certification a project manager must demonstrate a high level of understanding and knowledge about project management and those granted the PMP certification must also demonstrate ongoing professional commitment.

Anyone applying for PMP Certification must hold a university degree and have a minimum of 4,500 hours of project management experience in Initiation, Planning, Controlling, Execution and Closing. They must also have at least 3 years of project management experience within the last 6 years and at least 35 hours of project management training.

SWOT ANALYSIS

SWOT is an acronym of Strengths, Weaknesses, Opportunities and Threats and is used to help with decision-making in the planning and risk elements of large, complex projects.

But it is not purely a method used for controlling areas of planning and risk - it is also used to highlight areas of the project that could be maximised to the benefit of the whole project or individual areas where some competitive advantage may be gained. It is used to evaluate particular activities of the project in order to optimise their potential as well as to evaluate risks in order to determine the most appropriate way of mitigating those risks.

SWOT analysis is normally performed during the initial project start-up phase so that the elements of the analysis can form the basis of the project plan, but it can also be used later in the project if the project is running into difficulties with scheduling, deliverables or budget and needs to be brought back on track.

SMART

Smart is a method within project management designed to ultimately achieve a goal or aim. Goals have a much greater chance of being accomplished if they follow the Smart philosophy which is a mnemonic for Specific, Measurable, Achievable, Reasonable, Time-bound.

Goals or tasks must be clear and unambiguous so the project team knows exactly what is expected, why is it important and who’s involved. Clear criteria for measuring progress must be set so you know whether the team is making progress towards successful completion. 

The goals must be achievable – if expectations are too high (or too low) then they tend to be ignored. They must also be reasonable or realistic, given your specific resources, so they represent an objective towards which the team can work. Lastly, every goal should be set within a time frame and have a target date. Without deadlines it is difficult to focus on completing a task.

PEOPLE

Remember that the people involved in the project are the key to whether it is delivered successfully or not. Develop, encourage and motivate the project team because an enthusiastic, committed team of people can often achieve more than expected. Deal diplomatically with the stakeholders to ensure that business politics do not become a risk to the project and communicate clearly with the client or end-users to ensure they understand fully what to expect when the project is completed.

Reasons Why Projects Fail

It is always difficult to be precise about the causes of project failure for a number of reasons. Our human inclination is to avoid any blame being attached to us, no matter how much we might proclaim the benefits of a no-blame culture, when it comes to our own career on the line, we don't want to stand up and take full responsibility for the failure ourselves. So clients will blame the project manager, the stakeholders will blame the business analyst for inadequate requirements, the project manager might blame the client for a poorly articulated business case but none of this helps to define the real cause of the failure.

Questionnaires can be used to gather information on the causes of project failure, but the questions are usually too general and the answers given to the questions are biased depending on the role the individual played in the project. There are also, frequently, several different reasons which contributed to the project failure so such questionnaires make it difficult to pinpoint the exact reasons for failure.

Add to this the fact that many projects are completely unique: with objectives, scope, technology etc that have not been experienced before and it is understandable that assessing the true reasons for project failure is extremely difficult. Nevertheless, if you take note of some of the reasons regularly cited for project breakdown they might help you to avoid disaster in your own projects.

The most commonly identified reasons are:

• Deadline missed
• Budget exceeded
• Poor communication
• Requirements not met
• Inadequate quality of final product/service
• Poor planning with respect to risk management, estimates and schedule
• Poor client - supplier relationship
• Final deliverable not acceptable to the client
• Lack or professional / technical skills within the team
• Failure to manage client expectations or unrealistic expectations
• Poorly defined or incomplete requirements
• Frequent changes to requirements and/or specification
• Weak business case
• New technology did not live up to expectations
• No support from senior management
• No involvement from end-users
• Limited Resources
• Lack of focus on the business needs


Some of these reasons are the result of an underlying failure. For example, a poor client-supplier relationship is usually the result of poor communication or communication that lacks detail and fails to manage client expectations.

And some of the reasons are not actually the reason for the failure but simply the outward manifestation of the project failure such as a deadline not being met. The reason the deadline was not met is actually the reason for the project failure and that could be any number of things such as failure to understand new technology, staffing issues, skills issues etc.


So if we accept that there are problems in genuinely determining why a project failed, we cannot fully understand the failure and so avoid making the same mistakes again. All the more reason why an experienced project manager is vital on major projects and why that person should have undertaken professional project management training. The experience will assist in avoiding problems that have occurred before and the training will provide the skills to deal with those problems that are unexpected and new to everyone.

So next time you are conducting, or involved in, a post-project review to analyse the causes of a project failure, try and look below the surface of the standard answers and resist the temptation to rush on to the next project and put the failure behind you. You just might learn a worthwhile lesson that could help you during your next project.

Typical Project Risks

Risks exist in every area of a project but the likelihood of a particular risk occurring, and the consequences to the success of the project if it does occur, are the main factors to consider in risk management within a project. It is important that the project manager does not expend too much time and energy on the risk management of those risks that are unlikely to occur or those that will have minimal impact if they do. This is why all risks should be categorised at the outset of a project.

Take a look at these common sources of project risk to help you identify potential risks in your project.

The Scope

• Scope not clearly defined in the Business Requirements Document
• Scope not defined in enough detail
• Different stakeholders fail to agree on scope
• Changes to requirements requested mid-project
• Acceptance criteria not documented
• Requirements not approved by all interested parties
• Business priorities change during the project


The Technology

• Team members have no experience of new technology being used
• Limitations in the software
• Software performance issues
• Integration with existing technology has not been tried and tested
• Data conversion limitations



The Equipment

This could be computer hardware or manufacturing equipment required to make a new product.

• Equipment breaks down
• Performance/Production speed is too slow
• Equipment capacity is too low
• Test environments not available

The People

This area can relate to internal staff and external staff or sub-contractors. It can also relate to the customer.

• Team members assigned to the project do not have the right skills
• Key team members leave before the project is finished
• Team members are not motivated
• Team members do not make adequate progress with tasks
• Team members are not available for meetings
• Team members do not follow schedule
• Staff involved in specifying the requirements are replaced
• Customer does not approve interim stages
• Customer reviews not carried out
• Adequate customer resources not assigned to project
• Resistance in some parts of the customer organisation to the project
• Unrealistically high customer expectations
• Lack of customer responsibility for the project


I haven't mentioned the project manager in this list of potential "people" risks but it could also be the case that the project manager is inexperienced or has no experience of a particular type of project. This will result in the project plan itself being a cause of risk, with potentially poor estimates, a poor grasp of dependencies and failure to manage the people, time and budget well.

Hopefully, the project manager will have a good grasp of formal project management techniques gained through professional training on one of the many project management courses available so that the schedule itself is not one of the potential sources of risk.

Ten QA Tips for Project Managers

Quality Assurance is the process concerned with monitoring the quality of all aspects of a project so that the final product fulfils all requirements. So QA is performed before the product is finished – it is an essential part of project management and one of the factors that will determine whether the project is a success or not. It can be a separate role from that of project manager but very often QA is just another one of those hats that the project manager wears from time-to-time.

Note that Quality Control is concerned with the quality of the finished product so is focussed on whether a product meets the original specifications and any additional guidelines for a particular type of product – essentially whether it is fit for purpose.

But let's just focus here on some tips about how to ensure your QA processes are adequate and that they will add benefit to your project rather than just be another bureaucratic procedure to be completed. Remember QA is not designed to keep the auditors happy but to help make the project a success.

1.      Get involved in the change management process to assess any quality issues with incorporating changes.

2.      Ensure that all changes to specifications are approved – a list of approvers should have been included in all original documentation

3.      Update project documentation with approved changes and distribute to all stakeholders using the communication plan to determine how and to whom the updates should be sent.

4.      Elicit feedback from stakeholders about the adequacy of the reporting from the project manager and/or team.

5.      Perform regular quality audits and document any potential quality problems.

6.      Where differences exist between what was expected and what was delivered or performed (from any task or process) try to determine and document the cause of the discrepancy.

7.      Manage the preparation of test environments and documentation of test cases.

8.      Ensure expected test results are fully documented.

9.      Ensure test results are reported to stakeholders and approved by them.

10.  Report all problems with test cases and test results to approvers and stakeholders.