The Quick But Essential Guide to
Project Management
By Mike Young
Published by Mike Young
First published October 2011 : This edition May 16, 2012
Smashwords Edition
Copyright 2012 Mike Young
Smashwords Edition License Notes:
This ebook is
licensed for your personal enjoyment only. This ebook may not be
re-sold or given away to other people. If you would like to share
this book with another person, please purchase an additional copy for
each recipient. If you’re reading this book and did not purchase
it, or it was not purchased for your use only, then please return to
Smashwords.com and purchase your own copy. Thank you for respecting
the hard work of this author.
Discover other titles by Mike Young at http://www.smashwords.com/profile/view/mikenyoung
***~~~***
What are Quick but Essential Guides?
Why is this book different? Is this book right for me?
What is a project? Goals and deliverables
Successful projects rely on team members
The planning, execution and monitoring cycle
Planning : creating a task list
Acceptability is judged in the round
The Dark Arts of Project Management
Warning signs that a project may be failing
Responses to a project that may be failing
Beefing up internal resource / adding outside resource
Flexibility and responding to change during the life of a project
Improving poor morale on projects
Trusting people to get the job done
Remember that project managers are replaceable
Ideas for making projects more fun
My thanks and let me know your thoughts
What are Quick but Essential Guides?
This is a growing series of ebooks that aims to provide down to earth, practical advice on topics that interest you. Drawing on years of experience, the books are short, easy to read and contain just enough information to help you get a sound grip on a topic and then quickly put that knowledge into practice.
Ebooks are a great resource for today's world because they are portable and always accessible on your smart phone, notepad, laptop, ebook reader or other piece of personal technical wizardry.
People who are:
+ just starting out in project management
+ more experienced, but wish to refresh their knowledge
+ experiencing a difficult project and are looking for ideas on how to fix things
+ looking to make their project work more fun and rewarding
Why is this book different? Is this book right for me?
It is true, there are lots of good books on project management. What is different about this one?
I have worked on projects for more than 25 years. When I started out I was keen to learn about the technical aspects of project management. How to create a plan. How to estimate. How to measure progress. What project methodology (approach or system) to use. What project software to use and how to use it. These are, of course, all good things to know.
But what I gradually came to realize was that all these technical aspects are just one, rather small, part of the art of managing projects. Pretty much all the rest is about people. It is the things that people do that make projects succeed or fail. So this book has a primary focus on the people side of managing projects. I do talk about tools and techniques, but my aim is to get the balance right.
So if you want to learn about people and projects keep on reading. If you would like to focus instead on project methodologies and Gannt carts, then you may wish to Google 'project management methodologies' or check out some of the other search ideas at the end of this book.
Minimal jargon. I promise to keep jargon and technical terms to an absolute minimum. There is far too much jargon in this world and it is perfectly possible to be a great project manager without using any jargon.
Keeping it real. Some books on project management are a little theoretical and sidestep some of the real world issues that you can encounter in managing projects. I promise to balance theory with practical, real world, advice.
NOT one size fits all. I will not try to pretend that all projects are the same and made equal. I firmly believe that one of the greatest arts to successfully managing project is adapting your project management approach to the type and scale of project and to the resources that are available. I promise to show how you can adapt your project management approach to suit different situations.
A little bit more fun. I promise to show how it is possible to deliver successful projects and have just a little bit more fun along the way.
***~~~***
Getting a feeling for what projects are all about.
What is a project? Goals and deliverables
A project is a group of people working together to achieve common (shared) goals - in other words to get something done. Of course you can have a personal project that you work on alone, but they are a totally different beast and are not the subject of this book.
What can we learn from this simple definition? There are two key points. 'People' are involved in projects…and whenever people are involved in things the capacity for both good and bad things to happen is ever present. Secondly…'achieve common goals'…projects have one or more goals (sometimes called 'objectives') and also outputs (often called 'deliverables'). The goals must be shared by the whole team. If goals are not shared, it means that the team is pulling in different directions, which is likely to put the success of the project in jeopardy.
For example: the goal of a construction project is to build a house/office/factory/road etc within a defined budget and timescale. The deliverables of a house build project are, for example:
+ the plans for the house
+ a completed house
+ a certificate from a building inspector confirming that the house has been built in accordance with the plans and relevant regulations
Usually, a project will have a few goals (possibly only one) and then a larger number of deliverables.
The definition of budget and timescale may initially be quite loose. Indeed many projects have no explicitly defined budget.
Projects should be fun and can be extremely rewarding. On the best projects you will experience a real feeling of accomplishment. With luck (and I always believe in making your own luck) your success will be recognized and rewarded.
However, you should expect the majority of products to be difficult and challenging at times – that is the nature of project life. In the difficult times, try to keep a good sense of perspective and do not let the project 'swamp' you. You should also be wary of changes to your personality that can occur when you are operating under extreme pressure. For example, it is easy to fall into the trap of relying less on others and doing more yourself when pressure increases. Of course, such an approach simply makes your problems worse. When times are difficult I would recommend increasing your focus on the really important things and spending less time on details and items that are less critical to project success. Clarity and prioritization will go a long way to helping you get by.
Just remember that there is fantastic value for you both personally and as a team from learning and experiencing how to work through the difficult times and successfully overcome those challenges. At the risk of sounding like your mother, living through project successes and failures will make you a better person and a better manager.
Follow this link for some ideas on how to make project life more fun.
Not an easy question to answer! This is because different organizations define the role and expectations of a project manager differently. The basic job of the project manager is to create a framework for the project team to succeed and then ensure that the project succeeds in meetings its goals.
A project framework includes:
+ a project plan (and sometimes a project budget) and a mechanism for tracking progress against the plan
+ the right resources (people, equipment, a place to work etc)
+ a project sponsor who desires and promotes the success of the project and is responsible for defining (or ensuring the definition of) goals, broad timescales and budget (if applicable)
+ a means of involving stakeholders in the direction of the project
+ a means of communicating effectively between project team members and also with any other groups that the project interacts with
+ a mechanism for capturing conflicts, issues and risks and managing them through to a satisfactory outcome
Ensuring that the project succeeds implies:
+ Continually reviewing achievement of goals and progress against the plan to ensure that the project is going to produce the required deliverables in the expected timeframe
+ Making sure that any changes to the scope of the project are made consciously, with the agreement of the stakeholders and with full knowledge of the implications of the change
+ Making sure that the project continues to have the right resources
If you are asked to be a project manager it is important to understand what type of project manager you are expected to be.
Here are two examples of different kinds of project manager role. I am painting them at the opposite ends of a spectrum and you may find that you have a role somewhere in between these two extremes.
Project Manager as Facilitator and Coordinator. This type of project manager focus on the plan and tracking progress. Project team members look to their own line managers for direction. Where there are issues to be resolved or questions of priority, the project manager seeks to resolve these via consensus or in consultation with project stakeholders.
Project Manager as Leader. This type of project manager is an extension of the facilitator/coordinator. In addition to the role of a facilitator/coordinator, this type of manager takes a more direct role in day-to-day management of project team members. They are more hands on in allocating and directing resource, making prioritization decisions, resolving issues and encouraging project team members.
The essential difference between the above two types of project manager relates to control/direction of resources. The facilitator does not control project resources, whereas the leader has at least some measure of control over resources.
Successful projects rely on team members
Regardless of whether the project manager is a leader or a facilitator, the success of any project rests with the team members. Team members do the bulk of the work and they have the skills, knowledge and enthusiasm to get the job done. A project manager cannot succeed with the help of team members. Never underestimate the contribution of the team and the ability of the team to help a project manager deliver a project successfully.
I make no apology for stating something that perhaps appears blindingly obvious. Because, unfortunately, I have met one or two project managers who appear to believe that they alone are responsible for the success of their project. A bizarre mistake that I am sure that you will avoid and be lucky enough not to ever encounter as a team member.
Probably the most important differentiator between projects is that of size. There are SMALLER and BIGGER projects. SMALLER projects tend to have:
+ shorter duration
+ less people
+ less ambitious goals/objectives
+ less deliverables
+ less complexity
+ less risk
Naturally, BIGGER projects tend to be the opposite.
In all project laws known to mankind... SMALLER is better (by a long, long, long way). SMALLER projects are easier. Easier to mange, easier to communicate within, easier to change direction if something goes wrong. Easier, easier, easier.
There is another big enemy of projects that also tends to favor SMALLER projects: Time.
The longer a project lasts, the more bad things can happen. Bad things like:
+ Your project sponsor leaves or changes jobs. The new sponsor may not be bought into the project and could disown it.
+ Your company executive team changes potentially resulting in a change of direction.
+ A new technology comes along that makes the current project direction outdated (particularly in IT projects).
+ The financial circumstances of the company change, making cost savings necessary.
+ Your company gets bought by a rival or acquires a rival.
+ Priorities change, making the project less important or resulting in cancellation.
+ The company gets project fatigue, begins to question the investment being made, the lack of results...you get the picture!
So whenever you see a project with an expected timeline that lasts more than a year, feel free to start to getting worried. And the longer it gets, the more worried you should be. Don't get me wrong. BIGGER projects can be successful. It is just that they tend to have more failures, more major delays and larger cost overruns (as measured by a percentage of original budget).
It is also worth noting that SMALLER projects are easier to get approved and initiated in most organizations. This is simply because most executives and management teams are wary of the risks and costs of BIGGER projects.
Time is such a big project killer that here are entire project methodologies (ways of working) that are designed to address the higher risk that comes with longer projects. One example in the IT world is 'Agile Development'. These methods rely on very quick delivery cycles. In my last Agile project, we delivered new IT system functionality into live operation once per month.
Unfortunately there is not space in this book to go further into Agile techniques, but I would encourage you to learn more if you can. Agile development is also a topic for a future Quick but Essential Guide.
To get a feeling of some of the human issues involved in project life, it is useful to compare projects to wars. In fact, wars are projects. I would hazard a guess that in the long history of mankind as a social animal, going back 10s of thousands of years, wars are the oldest examples of projects. Wars:
+ have goals: eg beating the enemy, occupying a country
+ need plans
+ require organization of individuals who are unused to working together
+ are made up of troop movements and battles together with lots of intermediate goals and lots of sub-projects
+ are always subject to limited resources…there are never enough men, materials, or time to get the job done properly
+ are confused, communication is poor, accidents happen, things go wrong
+ involve lots of arguments and differences of opinion on what the goals should be and how to go about achieving them
+ need accurate feedback on what is happening…so that Generals can initiate next steps and react to changing circumstances
+ have a political dimension…these place constraints on what can be done and how it can be done
+ require changes in direction, sometimes at short notice, to accommodate 'events'
All these things apply to projects in your business. Nobody expects the path to victory in war to be smooth, so we should not expect all projects to run like clockwork either.
There is a minimal set of things that a project needs in order to be defined. Without any one of these things, your project is not a project and would be in a serious trouble. So, your project must have:
+ Goals/objectives
+ Deliverables
+ Timescales and milestones
+ Resources
Please note that I am making no judgment about how any of these essential elements are documented. In my view, documentation can be as short or long as you like, except that it must meet the needs of your particular project. In other words, for a really SMALL project a simple email may cover all of these essential project definition elements. For a BIGGER project, you may needs 10s of pages to properly define these essential elements.
(This is where I strongly diverge from some project methodologies such as PRINCE 2. PRINCE would have you believe that any and all projects need a Project Brief together with a Project Initiation Document (PID). But in the real world I have seen more so called PRINCE 2 projects without key documents such as these than with them!)
As projects get BIGGER, more documentation is required to help in the process of planning, tracking, communicating and coordinating.
The important thing is to match the documentation to SMALLER or BIGGER and also remember that good documentation is a 'means to an end' and not a goal in its own right.
In many cases we do not need special tools to successfully manage a project. It is possible to manage projects quite well with just email, word processor and spreadsheet software.
On BIGGER projects, specialist software can sometimes be helpful. There is a wide variety of software to choose from, but often people choose 'Microsoft Project'. Personally I am not a great fan of Microsoft Project, probably because I find it a little complicated. However, if you become a proficient user, it can be a good tool when the number of tasks and dependencies increases.
Web based project management and project collaboration tools are becoming popular. One that is well-known and easy-to-use is a tool called 'Basecamp'.