The converse argument to my 'lead time' post is the importance of actually doing something. Many projects are good idea going nowhere. If you want your good idea to go somewhere, you need the project to get underway. The purpose of your lead time is to make appropriate preparation for the project. If the project never happens due to indefinite lead time, you have wasted your time.
If you are concerned that the project is too big, and that is holding you off from starting, you might want to consider the potential for a pilot trial (a little implementation that mimics the actual project outcome), or starting the first few activities, if you are confident that you will learn enough to continue the project. Do this with caution, as projects can gain a momentum of their own that is unrelated to the relevance or value of the outcome.
Thursday, October 25, 2007
Lead Time - We Never Seem to Have Enough
Hi,
Here is a quicky - a sidebar regarding lead time. There is another one following about avoiding excessive lead time - we project managers need to be able to find a balance between each.
...Geoff
CONTENT:
Much of the pain we suffer by ignoring the 7 Ps can be attributed to the compulsive manner in which we continuously persist in going at projects ‘like a bull at a gate’. We do not expect rats in a maze to sit down and puzzle out the problem with which they are confronted, but we should expect it of our project managers. And tragically, many people who profess to expect it of their project managers continue to place undue pressure to start projects well before they and the organisation are ready.
The term ‘lead time’ refers to the amount of time we give ourselves before something is to happen to prepare for it to happen. When we talk about project lead times, some people persist in saying, ‘we know what needs to be done, let’s get on with it’. What they usually mean is ‘I think I know what needs to be done; and I can’t be bothered taking the time to write it down and I can’t be bothered making sure everyone else knows what I know’. This is fine if you have no stakeholders and the outcome will not affect other people, or if the job is simple enough to get away with not planning.
The bottom line is, we need plenty of time to plan projects before we start projects. If you are not sure how much lead time to allow, take a guess and double it. If you are going to select a Project Manager during the lead time, add the time it takes to get a Project Manager to the lead time too.
Here is a quicky - a sidebar regarding lead time. There is another one following about avoiding excessive lead time - we project managers need to be able to find a balance between each.
...Geoff
CONTENT:
Much of the pain we suffer by ignoring the 7 Ps can be attributed to the compulsive manner in which we continuously persist in going at projects ‘like a bull at a gate’. We do not expect rats in a maze to sit down and puzzle out the problem with which they are confronted, but we should expect it of our project managers. And tragically, many people who profess to expect it of their project managers continue to place undue pressure to start projects well before they and the organisation are ready.
The term ‘lead time’ refers to the amount of time we give ourselves before something is to happen to prepare for it to happen. When we talk about project lead times, some people persist in saying, ‘we know what needs to be done, let’s get on with it’. What they usually mean is ‘I think I know what needs to be done; and I can’t be bothered taking the time to write it down and I can’t be bothered making sure everyone else knows what I know’. This is fine if you have no stakeholders and the outcome will not affect other people, or if the job is simple enough to get away with not planning.
The bottom line is, we need plenty of time to plan projects before we start projects. If you are not sure how much lead time to allow, take a guess and double it. If you are going to select a Project Manager during the lead time, add the time it takes to get a Project Manager to the lead time too.
Friday, October 19, 2007
The 7 Ps
Hi,
This topic is all about getting some key things done before the project starts properly.
CONTENT:
My friend Michael introduced me to the concept of the 7 Ps more than 15 years ago. Often people ask me how they could have prevented the problems they are currently experiencing, and I find myself telling them about the 7 Ps. Sadly the 7 Ps is one of those concepts often labelled ‘common sense’, but less commonly applied.
(Caution, minor expletive follows.) The 7 Ps are Prior Preparation and Planning Prevent Piss-Poor Performance. For those of you of a sensitive persuasion, you can drop the word ‘piss’, and the point can still be made.
At a minimum, you need to know:
* What you want to achieve.
* Who you are doing it for.
* How you will go about it.
* Who will be involved.
* How you will keep track of progress.
* How you are going to start.
* How soon you need to/can be finished.
* How you will be able to tell that you have finished.
When you put these together, you will have a Project Definition.
If you are wondering what else could be handy at this point, you could find out:
* Whether your organisation has the will and the capacity to complete the project.
* Who can help the project to succeed, and how.
* Where the project will be undertaken, and whether this is the best place/space.
* How the resources you need can be secured by the project. (Resources include cash and people, and possibly other things.)
* What the known risks and issues are and how you will address them.
You can add these to the Project Definition to make it even more comprehensive.
Some people make a Project Schedule part of the Project Definition, but this will be described later.
...Geoff
This topic is all about getting some key things done before the project starts properly.
CONTENT:
My friend Michael introduced me to the concept of the 7 Ps more than 15 years ago. Often people ask me how they could have prevented the problems they are currently experiencing, and I find myself telling them about the 7 Ps. Sadly the 7 Ps is one of those concepts often labelled ‘common sense’, but less commonly applied.
(Caution, minor expletive follows.) The 7 Ps are Prior Preparation and Planning Prevent Piss-Poor Performance. For those of you of a sensitive persuasion, you can drop the word ‘piss’, and the point can still be made.
At a minimum, you need to know:
* What you want to achieve.
* Who you are doing it for.
* How you will go about it.
* Who will be involved.
* How you will keep track of progress.
* How you are going to start.
* How soon you need to/can be finished.
* How you will be able to tell that you have finished.
When you put these together, you will have a Project Definition.
If you are wondering what else could be handy at this point, you could find out:
* Whether your organisation has the will and the capacity to complete the project.
* Who can help the project to succeed, and how.
* Where the project will be undertaken, and whether this is the best place/space.
* How the resources you need can be secured by the project. (Resources include cash and people, and possibly other things.)
* What the known risks and issues are and how you will address them.
You can add these to the Project Definition to make it even more comprehensive.
Some people make a Project Schedule part of the Project Definition, but this will be described later.
...Geoff
Wednesday, October 17, 2007
What is a Project?
Hi,
A project management book must define a project, so here I go...
CONTENT:
My rule of thumb for determining whether something is a project is to ask whether I am likely to forget stuff or stuff it up. If the answer is yes to either or both of these questions, I feel the need to plan it out and act like it is a project. Different people will have a different level of capacity to ‘just get things done’, so there are no hard and fast rules distinguishing projects from other activity using this method.
Another perspective on what is a project is that it is something significant that brings us closer to the overall goal. In a business context, the overall goal can be described as the venture or the vision (depending how practical or visionary you are). This is generally something really big, like building the Sydney Opera House or raising a child well. The project could be selecting a design (of the Opera House) or choosing a suitable high school (for the child). Similarly to the method above, there are no hard and fast rules for distinguishing projects from other activity using this method.
Another method is to define what is not a project, and the rest of our activity must be a project (or be part of a project). What is not a project is routine or repetitive activity for which the planning has taken place in the past, leaving us with policies and procedures that can be followed; or trivial activity which does not require planning. Examples include telemarketing for a charity, checking the quality of fruit on a conveyor belt, or washing the car (after you have done it a couple or times).
So identifying a project can be tricky. Or maybe not tricky. Maybe we should acknowledge that it is a slippery concept, and that we are likely to have a difference of opinion on this at times.
There is another perspective on this, and it sounds very objective (but it isn’t), and that is the definition from the uber-project management textbook ‘Meredith and Mantel’* (p. 9), which states: “In the broadest sense, a project is a specific, finite task to be accomplished.” They need to provide a lot of follow-up detail to convince the reader that brushing my teeth is not a project based on this broad definition.
The follow-up detail they provide is useful, and involves describing the following attributes of projects:
* Importance to senior management.
* A one-time activity divisible into sub-tasks that require coordination.
* An organic life-cycle with a due date.
* Reliant on interdependencies outside the project.
* Unique to the organisation.
* Limited in resources.
* Characterised by conflict.
These are very good points, and provide a greater understanding of what constitutes a project. However I still feel we cannot escape the subjectivity of the label ‘project’.
So finally, a project is what you call a project. If it is spring cleaning, that’s fine. If it is upgrading from one SAP version to another, that is fine too. If it is building the Sydney Opera House, great, but you may be reading the wrong book – this is about small projects, not Opera House sized ones.
…Geoff
* Meredith, J.R. and Mantel, S.J. 2006 Project Management: A Managerial Approach, sixth edition, Wiley, New York.
A project management book must define a project, so here I go...
CONTENT:
My rule of thumb for determining whether something is a project is to ask whether I am likely to forget stuff or stuff it up. If the answer is yes to either or both of these questions, I feel the need to plan it out and act like it is a project. Different people will have a different level of capacity to ‘just get things done’, so there are no hard and fast rules distinguishing projects from other activity using this method.
Another perspective on what is a project is that it is something significant that brings us closer to the overall goal. In a business context, the overall goal can be described as the venture or the vision (depending how practical or visionary you are). This is generally something really big, like building the Sydney Opera House or raising a child well. The project could be selecting a design (of the Opera House) or choosing a suitable high school (for the child). Similarly to the method above, there are no hard and fast rules for distinguishing projects from other activity using this method.
Another method is to define what is not a project, and the rest of our activity must be a project (or be part of a project). What is not a project is routine or repetitive activity for which the planning has taken place in the past, leaving us with policies and procedures that can be followed; or trivial activity which does not require planning. Examples include telemarketing for a charity, checking the quality of fruit on a conveyor belt, or washing the car (after you have done it a couple or times).
So identifying a project can be tricky. Or maybe not tricky. Maybe we should acknowledge that it is a slippery concept, and that we are likely to have a difference of opinion on this at times.
There is another perspective on this, and it sounds very objective (but it isn’t), and that is the definition from the uber-project management textbook ‘Meredith and Mantel’* (p. 9), which states: “In the broadest sense, a project is a specific, finite task to be accomplished.” They need to provide a lot of follow-up detail to convince the reader that brushing my teeth is not a project based on this broad definition.
The follow-up detail they provide is useful, and involves describing the following attributes of projects:
* Importance to senior management.
* A one-time activity divisible into sub-tasks that require coordination.
* An organic life-cycle with a due date.
* Reliant on interdependencies outside the project.
* Unique to the organisation.
* Limited in resources.
* Characterised by conflict.
These are very good points, and provide a greater understanding of what constitutes a project. However I still feel we cannot escape the subjectivity of the label ‘project’.
So finally, a project is what you call a project. If it is spring cleaning, that’s fine. If it is upgrading from one SAP version to another, that is fine too. If it is building the Sydney Opera House, great, but you may be reading the wrong book – this is about small projects, not Opera House sized ones.
…Geoff
* Meredith, J.R. and Mantel, S.J. 2006 Project Management: A Managerial Approach, sixth edition, Wiley, New York.
Sunday, October 14, 2007
Problems for Small Projects
Hi,
OK, this seems a good way to find out whether anyone is reading this, and to get some input to the book at the same time. You can see from the entry ‘The Back Page’ that I have a bit of an idea of where this book is going, but to ensure it will meet the needs of its audience, I am going to ask you to use the Comments below to tell me what problems people responsible for small projects suffer, so I can make sure the book will be relevant.
From my experience, the problems people suffer include:
* Inadequate resources – for example, the required people and the actual people do not match.
* Inadequate planning – so people do not know what needs to be done by when to accomplish the eventual outcome.
* Lack of leadership – so we run around in circles at cross-purposes with each other.
* Meddling leadership – so we are not allowed to get on with the job to the best of our abilities.
I could go on, but this is your opportunity. So go on, respond…
In appreciation (in advance), …Geoff
PS. My friend Doug will probably want to add his comments about ‘management by committee’ here, and I’m sure he has some other ideas.
OK, this seems a good way to find out whether anyone is reading this, and to get some input to the book at the same time. You can see from the entry ‘The Back Page’ that I have a bit of an idea of where this book is going, but to ensure it will meet the needs of its audience, I am going to ask you to use the Comments below to tell me what problems people responsible for small projects suffer, so I can make sure the book will be relevant.
From my experience, the problems people suffer include:
* Inadequate resources – for example, the required people and the actual people do not match.
* Inadequate planning – so people do not know what needs to be done by when to accomplish the eventual outcome.
* Lack of leadership – so we run around in circles at cross-purposes with each other.
* Meddling leadership – so we are not allowed to get on with the job to the best of our abilities.
I could go on, but this is your opportunity. So go on, respond…
In appreciation (in advance), …Geoff
PS. My friend Doug will probably want to add his comments about ‘management by committee’ here, and I’m sure he has some other ideas.
Saturday, October 13, 2007
The Back Page
Hi,
Apparently it is appropriate to write the back page of the book before getting into the detail. I guess this is to keep me on target (like writing our Project Objective well before doing the Post Implementation Review, maybe even before we start the project).
...Geoff
CONTENT:
This book is for you if you are responsible for a small workforce that must accomplish predictable tasks. It is a practical resource for people responsible for small projects.
There are a small number of basic principles to managing projects. If you follow these consistently, you can be a successful project manager. This book explains these principles in simple English.
The principles include:
* The 7 Ps - prior preparation and planning prevents poor performance.
* Listen and Learn - stay close to the team and monitor 'the vibe'.
* Be Visual - care of Henri Gantt and others.
* Use Elegant Simplicity - plain English & vanilla tools.
* Focus on Outcomes - know the outcome and share this knowledge.
* Stay Close to Stakeholders - keep your friends close...
* Show Me the Money - budget, monitor, report.
* Are We There Yet? - finish off with style.
* And more, such as People Matter, Be Flexible and Be Part of the Solution.
This book also includes templates, such as Starting Out, Reporting Progress and Finishing Up.
...Geoff
(Please use the comments to let me know what you think!)
Apparently it is appropriate to write the back page of the book before getting into the detail. I guess this is to keep me on target (like writing our Project Objective well before doing the Post Implementation Review, maybe even before we start the project).
...Geoff
CONTENT:
This book is for you if you are responsible for a small workforce that must accomplish predictable tasks. It is a practical resource for people responsible for small projects.
There are a small number of basic principles to managing projects. If you follow these consistently, you can be a successful project manager. This book explains these principles in simple English.
The principles include:
* The 7 Ps - prior preparation and planning prevents poor performance.
* Listen and Learn - stay close to the team and monitor 'the vibe'.
* Be Visual - care of Henri Gantt and others.
* Use Elegant Simplicity - plain English & vanilla tools.
* Focus on Outcomes - know the outcome and share this knowledge.
* Stay Close to Stakeholders - keep your friends close...
* Show Me the Money - budget, monitor, report.
* Are We There Yet? - finish off with style.
* And more, such as People Matter, Be Flexible and Be Part of the Solution.
This book also includes templates, such as Starting Out, Reporting Progress and Finishing Up.
...Geoff
(Please use the comments to let me know what you think!)
An Explanation
Hi,
I have been planning to write a book called "How to Manage Small Projects", with a catchy but as yet not invented phrase to follow the title. The book has been in me for about a decade now.
I went to a workshop on how to write a book in the middle of this year ('07), which was actually about how to publish a book - which was lucky as I know a fair bit about writing, but little about publishing. Full of vim and vigour I finished* a plan for the book in no time at all (Aug 07) - mostly on my PDA while sitting at the school waiting for the bell to release my kids - I correctly figured that the limitations of the teeny-tiny keyboard would keep my plan short and to the point.
Now that the plan has sat for about two months, it is time to push on. This blog is my method of stringing out the whole process a bit further, as I am a bit scared of the self-publishing process. Also, as I have been trying to convince my Dad to blog, this is a good opportunity to lead by example.
Yours, ...Geoff
PS. I am keeping the plan a secret for now, but see CONTENT: The Back Page for some hints.
* For 'finished', read 'decided I'd identified enough topics to fill a book'.
I have been planning to write a book called "How to Manage Small Projects", with a catchy but as yet not invented phrase to follow the title. The book has been in me for about a decade now.
I went to a workshop on how to write a book in the middle of this year ('07), which was actually about how to publish a book - which was lucky as I know a fair bit about writing, but little about publishing. Full of vim and vigour I finished* a plan for the book in no time at all (Aug 07) - mostly on my PDA while sitting at the school waiting for the bell to release my kids - I correctly figured that the limitations of the teeny-tiny keyboard would keep my plan short and to the point.
Now that the plan has sat for about two months, it is time to push on. This blog is my method of stringing out the whole process a bit further, as I am a bit scared of the self-publishing process. Also, as I have been trying to convince my Dad to blog, this is a good opportunity to lead by example.
Yours, ...Geoff
PS. I am keeping the plan a secret for now, but see CONTENT: The Back Page for some hints.
* For 'finished', read 'decided I'd identified enough topics to fill a book'.
Subscribe to:
Posts (Atom)
