PROJECT MANAGEMENT & LIFE COACHING A SYNERGY
Background
A regular segment highlighting insights into Project Management Techniques gained over 14 years experience in the IT industry as seen by a practicing Life and Executive Coach. This is dedicated
to all the project/program managers who have taught me so much over the last 15 years, whether knowingly or not.
Project Management/Life Coaching Case Studies
SANE PROJECT MANAGEMENT v SICK PROJECT MANAGEMENT
What are some of the danger signs of a sick project?
This will to some extent depend on where you are observing this from?
These may be an indicator of unrealistic goal setting and punishing use of
all available internal and external resources to meet unachievable deadlines.
The following are cumulative in most cases and can gather a terrifying force
killing everything in its path hence the moniker "death march" project.
An announcement has been made in the press or media generally and/or internally
of a new approach, a new or enhanced product or service, a new strategy or a re-organisation
of some sort and a date has already been announced of when this new beaut thing will be running from
(not rolled out) but actually running in standard business fashion but the project has not even got off the ground
or even been contemplated by those areas responsible for its successful delivery (of which you belong as a PM). In good organisations, these strategies are driven from the respective internal organisations
responsible for them who have already brought on board the necessary resources to at least gear up from should
the project be given the go ahead by the board of directors or whatever clique runs the organisation. But in bad organisations
perpetuating sick projects these resources aren't on board, do not exist currently and the whole organisation needs gearing up to deliver to a rapidly
approaching deadline.
You, as the Project Manager, are brought on board with the constraints as above and with (or without knowledge) of the
announcement previously made by management. Your own management (your managers, supervisors) do not know the situation or are unwilling to know and
cannot help you.
Once appointed (and not before mind you), you are sweetly and kindly informed that "your" project is to deliver to the dates previously announced to the
staff and/or the press and/or the stock exchange. You are also informed the business sponsoring this project have as yet not completely made up their mind as
to the size, quantity, quality, color, time to market and all these other dimensions of the product and/or service your project is to deliver. You are also informed
that you, as the project manager, will be the sole program/project resource devoted to the project as they have not budgeted or quoted for anymore. You are also informed that whoever
quoted this project also quoted for and gave a fixed price to the client for the project deliverables.
This poses a number problems
Before you even begin formulating a possible project plan (scope) and then a project schedule with a resourcing model, a number of things should be clear to you
from the outset -
What drives your deliverables and help set the project scope and enable you to do a decent project plan that you might be able to baseline (read freeze) sometime down the track
is unable to be done at this stage. This is saying that you don't know because they haven't told what it is they want, they (the client) are still making up their minds about it. What they
(the people who engaged you whether account managers and/or internal business managers) is they still want you to go ahead with delivering what you think they think they want.
Going ahead at this stage is fatal and is symptomatic of most brutal punishing projects as they rush head long into this uncertainty.
You will now find that you will not have the time to formulate and prepare a project plan and scope because they won't give you the time to do it (and you will be busy with your delivery
responsibilities) and this lack of a scope that you can freeze is the beginning of your problems even though you have internally waived the requirement for one by going right ahead with the project.
This goodness on your part will come back to haunt you. Sleepless nights, terror, panic attacks, deep depression, suicidal thoughts and a deep deep unhappiness and anger that your kindness and willingness
to help has been massively taken advantage of by the business, by the account managers, by your managers and by their managers. As one of my managers put it, you shot yourself in the foot and how!
Because you have no scope, whatever schedule you may have crafted will be inaccurate as the business can and (in a death march project) will change the scope on you add things, take things away and so on.
You are now in reactive mode and getting out of control.
Everyone one of these scope changes (and in a death march project there are many) is driving the people who work for you on this project insane with the extra effort in recalculating what is required in terms of
equipment, resources, effort schedule changes and so on.
You are rapidly becoming Mr Unpopular.
One more scope change will drive you and/or your team over the edge.
Let's stop the action there and firstly decide what we should have done from the start of our appointment and
we will then expand on some possible strategies for dealing with the project as it now stands.
What are the guiding principles for ensuring you are not in charge of or part of a death march project
This is axiomatic of good project governance but do only enough work in the initial stage of a project to get to a point where
you can freeze the scope (sign-off the project plan). Once it is frozen, make it very very hard to change. In PM parlance this is known as project
change management. Get the person attempting the change lost in a sea of red tape. This is the change control board where all changes are examined and
analysed for impact to cost, schedule, quality, risk and every other dimension of the deliverable. Only if the CCB approves the change does it go ahead and the
project plan is changed to reflect it. This will then flow on to other project documentation and parameters.
Assuming you have done the above, then this is the most critical part of the process. Developing the schedule and then using it to run the tasking, reporting of
project activities. Why this is important is because where most project managers make a critical mistake. This is because of the reasons enumerated above to let the date of the deliverables
drive the dates of all the activities it is theoretically dependent on. In other words, use the schedule as a weapon of mass destruction to hold the project team ransom. What do I mean by that?
Well simply, because the deliverable date is frozen in the schedule (eg. the ship will be delivered to the customer on this date), then all the tasks and summaries cannot change to reflect the realities
of resourcing, supplier, quality and other common problems. The type of projects that normally driven by the end rather than the means are those involving legislation, that is, the government requires business
to implement a certain regime or service by a certain date or a company wants a reorg to occur by a certain date because a whole lot of people will be retrenched the day after (driver is money most probably) or
your competitor has a new service, you need a counter immediately so a project date driven is created.
Any project schedule which is date driven is an absolute waste of a project manager, project management tools
and holds the schedule and project team prisoner to meeting a particular date. Think about it logically, it is the availability of resources, people, goods, products, labour, designers, testers, engines, servers, computers,
fuel etc. that determine whether your product or service can be done. The schedule will tell you by what time it can be done. Let the schedule do what it does best and that is calculate your bottom line dates. This is a standard
recommendation from most project management tool vendors and that is avoid if you can fixed constraints and killer links that work back from a delivery date.
It goes without saying that the task dates are themselves driven by an accurate estimation of commencement and start date of tasks based on availability of resources. DO NOT BE TOO OPTIMISTIC HERE. Only estimate with what resources will
reasonably be available and working them to normal hours. Heroic efforts (working more than 10 hours a day continuously or more than 60 hours a week continuously has no place in the estimation process.
Adequate availability of project management resources (you), your support (program/project office), even your supervisor's time is essential to the good governance of the project and should be part of the critical path of the
project. Don't estimate ti will take you 5 days when in reality it will take you 30 days. Don't under estimate for anybody's sake.
Don't under promise and over deliver. This is the hero making syndrome. Or even worse don't over promise and under deliver, this makes martyrs of project managers but actually in both cases, it is the PM that brings it on themselves.
When determining delivery dates, don't. Let the schedule work it out for you based on what your team can reasonably deliver based on the resources and effort you have made available or provided to them. Deliver to the dates your schedule says it
can be done, not what you think the client wants to hear.
By all means, also keep a set of second books which has the client preferred delivery dates frozen in time, stone and regard and daily/weekly run a a variance report betweeen what your schedule and
people are telling you is achievable given the resources, work, effort and what you have been given by the client as frozen in time. Based on the variance analysis, tell the client if he or she wants to meet the dates enshrined in the frozen
schedule that additional resources, effort, tools, training, people, computers etc will be needed and you will not flog your people to death to meet the unrealistic deadline.
Critical Path. This is based on how you've set up your schedule but a critical path is a straight line or path between all those tasks between commencement and finish that are in a
predecessor/successor relationship. For example if the project to get you on Mt Everest culminates in line 500 Your person (alive hopefully) on Mt Everest then if task 45 is get Chinese govt permission and some of the following
tasks are dependent on it for example task 109 Journey through Chinese controlled territory, then conventional wisdom would say there is a critical path from task 45 to 109. Now if task 120 (Setup base camp) is dependent on task 109 because you can't get to base camp
unless you travel thru Chinese territory then the critical path is now 45->109->120 and so on hopefully to 500. This sort of makes sense but in another theoretical dimension makes no sense because you would think if you were personally paying to get to Mt Everest there wouldn't
be anything in the schedule (which you are ultimately paying one way or another) that is not a predecessor/successor to a task that will get you to Mt Everest otherwise what is its purpose in the schedule. This thinking leads to the problem that everything in the schedule is a predecessor/successor and
you would have a humongous critical path through every task. Now that is impossible. So which way to go. This is a bit like the part employees in organisations play. SOmeone once said you had better be serving the customer or serving someone who is. Now we're talking about those employees (read tasks)
many many times removed from the main goal/customer. How do you account for those? Is this the reason when two companies merge these employees are butchered in the carveup and made redundant, made to resign and otherwise monstered. Anyway, this is getting me off the critical path discussion. Most schedules
have hundreds/thousands of liens and only a critical path through 20 of them. If any item in the critical path changes in terms of completion date, then (assuming we have not frozen the deliverable date) the deliverable date will shift to happen later. On the other hand, if the deliverable date is frozen, then
you have nowhere to move, nowhere to hide you're in PM solitary confinement, the only thing to do is to bring to bear more resources (infinitely difficult based on above discussion) to not shift a critical path item end date. The question I have in terms of the critical path is those items in the critical path
are they not themselves dependents and have predecessors? For example to get Chinese govt permission, doesn't that require some major brown nosing and bribes and so on (and formal paperwork). The point here I think is that those items in the critical path may be dependent on other tasks but we do not put them in the schedule and
show them as predecessors to Chinese govt permission. If we did, then we would increase the critical path substantially. What use is the critical path at all? It is no less a measure of how we have painted ourselves into a corner to deliver a project based on nil time slippages and taking an optimistic view of the availability
of resources, weather conditions and other factors. Two PMS looking at the same schedule will probably come up with very diverse critical path. It actually depends on the type of PM you are. Sailing close to the wind and you'll come up with a critical path that is very unforgiving on the other hand an experienced, cynical PM might come up
with one that has has room for human foibles, weaknesses, mistakes and just human "don't give a rat's ass" attitude.
Question: What is the difference between tasks that find themselves on the critical path (essentially you, the PM make a subjective and value judgment about whether it should be a predecessor/successor to a task). As I said above, it depends on the PM what will be on the critical path? But does it matter? I think a PM shouldn't manage to a critical path.
A critical path only matters where your date for summiting Mt Everest floats depending on the availability/completion of all the right conditions/predecessor tasks to be in place. Even then and this why many people die summitting Mt Everest, people go for the summit even when the schedule tells them, they are not ready or should be summitting tomorrow or
the day after. They are obsessed by a fixed end date, not by what their schedule and common sense should be telling them is the right time to summit. A schedule with a fixed deliverable date is asking for trouble. There are also some kamikaze PMs who given a fixed end date, not only lock the schedule into that end date but promise to over deliver, that is, to come
under that date absolute madness/hero making (but at whose expense) take your pick.
So after all that, what is the critical path and what should it be used for?
To me it is like the software limited top speed on sports cars, you know it's there but you never go there. Know the critical path, if you put in predecessors/successors in your schedule are a natural occurrence of this because but creating this link, the critical path will follow it from Line 1 to Line 500. But use it only to drive the end deliverable date NEVER EVER the
set the end deliverable and drive the predecessor/successor tasks to somehow meet that date. For example, if you fix a date for doing something say 30 June but your resources are telling working current normal (even abnormal) hours you will not finish till 30 Sep then what do you do? Flog your resources to make then deliver by 30 June or let the schedule float to the possible
rather than the desired end date.
You can in theory design a project schedule where -
Every single task in it is required there
It is detailed to the correct atomic level (esp. if using a work breakdown structure - WBS). No task that is too detailed is there (eg. tie your boots on summit day but ensure oxygen bottles have oxygen would be right detail). It depends on the depth of knowledge of the PM.
and how many levels are in the schedule from the top level WBS, maybe 4 or 5 may be right and perhaps calculate the critical path from level 1 or WBS level may be right.
There is nothing in the schedule that shouldn't be there
Everything in the schedule is affects something else and is affected by something else in the schedule. If it doesn't, then you have too much detail there. Becasue you have detailed task which were you to change the delivery date would not affect the bottom line delivery date.
Everything in the scheduled is designed to complete the ultimate goal. It is either a critical path item or support a critical path item (should you go lower and say include an item that supports an item supporting an item that supports a critical path item - it is about common sense, you could if you wanted to create 500 billion line project schedule to build the largest passenger liner ever built the Queen Mary 2 but why would you but you may decide an appropriate level of detail and macro definition)and there are no other type of tasks.
For example, if a task (eg. pay Expedition Leader $5000) in the schedule does not fall in that category, then it should be removed. Maybe it is about before the project started and after the project goal completed (but closure is still required) or it is something that is there as a reminder for someone but in a 4000 line schedule how
effective is a one line reminder, that does not affect anything, that is, the payment does not trigger anything (it is not a predecessor for any coming/future task) and is not triggered by anything, that is, nothing needs to happen before the payment becomes due and payable (in legal terms there is no condition precedent), it has no predecessor tasks.
If you would like to engage me to review your project schedule and your critical path, please contact me on 0409 223 436 or alternatively send your schedule (in .mpp format only) to my email address.
A New Dimension to Project Management Human Dimension - Coaching/Mentoring/Friendship
The second in a series of articles show casing the project management and coaching synergy.
Throw away the text book that currently tells you, as a PM, how to manage the human resource dimension in your projects. You have most
to gain from this new approach and most to lose if you continue to slavishly follow the MBA texts.
Project Management Human Resources is unique in a number ways -
Your people are only with you the duration of a project, by definition something that has a start and end date;
You work extremely closely, intimately closely with them in some cases where there is real coaching happening but you do not
recruit them, manage them directly (or it can be said indirectly as well), they do no directly report to you except in those situations where
you have a dedicated project team whose members are in your line team and report to you for 100% of their activities;
These people report to you but you are not their line manager, they perform work for you but you do not have a part to play in their appraisal,
in their reviews, in their salary/bonus setting;
So how in heck do you influence them?
My program managers over the years have convinced me that there is a science to this, a psychology you can learn and apply,
taking lessons from behaviorism, industrial psychology and so on but I am here to tell you that it is not a science, you do not learn in a text book,
and in any case if you apply something like that consciously you'll be unmasked as a fraud. In this instance, only true genuine feelings and emotions work.
If as I say you can't teach it, why am I writing about it as if perhaps you can.
I say you can't teach it yes, but I will describe some circumstances in which applying (rather I mean here being), don't consciously apply anything
here, has found me in the zone with my people. As one against the wind. These are some points to think about -
When you are new to people, they relate to you better if you are genuinely humble and display humility (not subservience). The person who said "to teach is to
learn twice" nailed what I'm trying to say. This is especially so if you happen to be in a position of authority over them (for a PM, its pseudo anyway). Bring a genuine environment with you of openness and wonderment at the world.
Hemmingway - "When people talk, listen completely. Most people never listen".
Earn their trust and be in their good graces. Do what it takes to make sure that they're on board. I'm not going to talk too much about the mechanics of project management as such. Here I mean, discuss with them, what the best way of doing things here, listen,
take note and make changes to your approach accordingly.
In fact, be seen to be doing that, seriously doing that. After all they are the experts, let them shine. You're the male dancer in the duo, your sole job is to make them look good
and by making them look good, you'll hopefully look not too shabby but it actually doesn't matter how you look, the key here is they know you will listen to them. This removes one huge thing with a new project, the fear of the unknown
project manager imposing impossible ways of doing things. Your job here is to reassure them, you will do no such thing. You will listen to them, take heed and change accordingly.
Genuinely make friends with them. The old adage of not making friends with people you manage is absolutely dead and never had any validity, if it ever once did. Get to know them and their circumstances and their lives.
Be genuinely interested in what they did on the weekend or what they talk of. Have lunch with them.
On the closure of one of my most important projects which lasted a year, I hosted an evening where I invited all team members to a local club, stood drinks for a number of
hours and provided snacks, all at my own expense. I made sure they were all happy, had someone to talk to (if not me) and i kept the conversation going all night. It was a very positive atmosphere and quite wonderful. That is why two years later I can recall it
with true fondness and happiness.
The organisation I worked for would have no inkling or idea of the right thing to do. The lesson is even if the organisation is not with you and you know the right thing to do,
go right ahead and do it. You will never regret that you knew something had to done but never did it. This is really not about organisations but about how you within a perhaps constrictive, hierarchical, moribund organisation can
excel in your dealings with your team, your colleagues, your friends. Organisations rarely, if ever, penetrate to the layer I'm talking about.
If you call yourself a PM, be a good PM especially in their eyes. You won't get off first base if you not a technically competent PM. Do your homework before you come to meetings, know your work, know your project plan, your schedule,
your critical path, who is doing what, what their individual strengths and weaknesses are (and your own), it's basic but all the connection above ain't going to happen if you are perceived as being hopeless as a PM.
This is about being humble from a position of pure strength.
Always immediately it is apparent to you admit an error, a mistake or a faux pas. Never dwell on one if some else has made one or admits to one. Never conduct witch hunts or find someone to blame if the schedule/cost/quality slips. The bell here tolls for thee. Look in you solely.
Try to be genuinely interested in the subject of specialist knowledge you team members share, express amazement at how good the technology is, the design of the widget or whatever. Occasionally, show you're picking up the knowledge and understanding by a phrase dropped casually or
whatever.
When you discover weaknesses in your team or in one of your team, whether as a result of a failed project product such a schedule, cost or quality slip then take action.
But before you take decisive action, think of it in terms of their Life Coach. How best to approach it and tackle it together. I have written elsewhere about the possible approaches and I won't repeat myself here.
On the other hand, excellent performance doesn't come about by accident. You as a PM should encourage it by words and deeds and where evident you should expose it and praise it.
Do not apply numerical, statistical, KPIs, SLAa, KRAs or other numbers to chase or chastise your people. Always in discussion with them stick to non numeric dimensions. Put good performance on a pedestal.
Project Management Project
I am writing a book about my PM experiences. This is the first draft of it.
When and in what circumstances should you consider using a Life Coach?
What should a Life Coach do for you?
Preparing for Life Coaching
How to consider, select, engage and evaluate the performance of a Life Coach
Life Coaching Life Cycle
Setting Realistic and Achievable Goals
Learning from Failure as a Key to Future Success
Captain EJ Smith, RMS Titanic - a Life Coaching Study
The Skills and Tools Audit
Life Coaching Pro Bono - (and it's not about doing something for U2 lead singer Bono)
[Your Entry Here]
Life Coaching Tips & Techniques No. 7
Life Coaching Tips & Techniques No. 8
Please call me on my mobile (0409 223 436) for a confidential discussion to begin the journey of self discovery. You may prefer to email me your situation and your desired goals. Your details will be kept strictly confidential.
^ back to top ^
|
