The Project Plan is Your New Best Friend
Project success is, among other things, very much dependent on all the team members knowing what to do. Since it is not possible for the project manager to be constantly holding her team members hands the best way to keep the team members informed about what needs to be done is an up-to-date plan. The project plan, not to be confused with the project schedule, is a great vehicle to convey to the team members and other stakeholders the intended output of the project, what needs to be done, how and when.
All too often have we seen that the project plan gets a lot of attention at the start of the project and then gets forgotten. Keeping the project plan up-to-date has multiple benefits.
First of all it forces you as the project manager to review the currency of the plan and in particular the business case.
Secondly it ensures that the team members have a way of knowing how the project is run and what needs to be done.
Having an up-to-date project plan is one of many concurrent means, you as a project manager need to employ, to keep your team and other stakeholders informed. Finally we like to suggest to review the plan on a regular basis with your teamleads and key team members.
This lesson learned is also related to the plans are like food lesson learned.
From the Beginning Involve End Users...
... and involve them often.
The ultimate measure of success for your project is whether or not it meets the needs and requirements of the end users.
No News Is Good News...
… and only good news is bad news.
Projects thrive in an environment of trust. It is therefore critical that a Project Manager has clear expectations and has been entrusted with clear boundaries for authority and decision-making without having to ask permission from Executives every step of the way.
Under these conditions, a project can move along involving Executives at predetermined moments and gates such as the end of a project stage and beyond that knocking on the doors of the corner offices only if certain predetermined tolerances are passed and serious events may occur. This is called management by exception.
Considering this approach and reflecting further on the title of this article, if reports up to Executives from a Project Manager are always good this can also mean that problems may be going unreported or unnoticed. Think about, on any project there are very likely moments things go not as planned or simply go wrong. Therefor, Executives who only receive good news reports, should take this with more than a grain of salt - more like a very bad sign - statistically speaking.
Enough is Enough
On a project, enough is enough.
What this means is that you must provide any person only the level of detail of information that person needs at that time. Think of it, when you are packing your suitcase for a vacation, do you really need to know that the average temperature over the last 50 years for that month is 28.53987 degrees? No, you do not. All you need to know is that the average temperature is between 25 and 30 degrees, or between -10 and 0. It will make a big difference on what you pack, or not.
Providing too much (too detailed) information, particularly to executive levels of authority, is not only a waste of time and effort but also a big risk. The risk being that people get caught up in details, and that they completely miss what is really important.
We see this time and time again in project meetings; Project leads/manager/members being grilled about an apparent incongruity of details between reports. The issue at hand, that the project is over budget, gets ingored and the project member gets send back to write yet another report explaining the reason(s) for the difference.
In the same way that just-in-time management streamlines processes, just-enough-information management streamlines communication and decision-making. Don’t give people an excuse to talk about details that do not matter at that moment. Enough is enough already!
Explain the Rationale Behind a System Choice
“Alice came to a fork in the road. 'Which road do I take?' she asked.
'Where do you want to go?' responded the Cheshire Cat.
'I don't know,' Alice answered.
'Then,' said the Cat, 'it doesn't matter.”
'Where do you want to go?' responded the Cheshire Cat.
'I don't know,' Alice answered.
'Then,' said the Cat, 'it doesn't matter.”
- Lewis Carol
Alice in Wonderland
In other words, if on one hand you don't mind what a system does there is no need to know why it works the way it does. If on the other hand you do mind what a system does and you do mind that it works and that the people using it use it correctly then you better explain early on and often the 'why' behind the choices that are being made in the organization project.
We once worked for a client who did not explain to the end-users the selection of a certain system had more to do with dislike of the previous system and its system provider and less to do with like for the new. This turned out to be a costly mistake as the users really liked the old system and never really accepted the new system. After a few years the organization had to back track on its steps and go through a costly revision of the system.
If this organization would have explained the reason for switching had more to do with a falling apart between them and their provider they would have probably still have had to do a lot of convincing but in the end the system would have been accepted.