Project Management: deadlines must be agreed?

It is one of the major and most challenging tasks of a project manager to build a time schedule.

The exercise is of course the foundation of the more general plan as it establishes the start and the end if the project and gives a clear frame to the execution.

Unfortunately inputs for building the schedule must align from many stakeholders and their interests are very often (almost always I would say), completely opposite.
From the top management generally sponsoring a project, the request is permanent acceleration. Therefore aggressive deadlines are never aggressive enough. On the other hand, people who have to execute the tasks, in the majority of the cases, tend to be either too optimistic or pessimistic. In the first case silent killers able to spoil the schedule are the underestimation of the effort or not evaluating concurrent tasks, or simply the complete absence of contingency in the proposed delivery date.

For pessimists, the achievable delivery date is so much pumped with risks mitigation that it would not fit in a geological age...

Both tendencies have to be taken in account from the PM building the plan. But, another hidden enemy, is the passive acceptance of management requests without getting an appropriate feedback from the team. Putting just on the table the requests and not testing their feasibility, will later explode with an unexplainable delay.

Solutions? Not a single one. Ideal world does not exist and there is definitely not a single process solving the issue.

What must be always present in the PM view is that nothing gets written in Stone and a plan changes continuously. So, the nice painted MS project must be revised and communicated again and again. Alarms must be detected when things are going wrong.

But last and not least, the PM cannot believe that not negotiated and agreed dates, both coming top down or proposed bottom up, will simply fit together: they are fundamental triggers for further alignment.

That magic chemistry to achieve the expected results is what a PM is paid for...

Assumptions and their verification

A real case.

I was leading a small software development project for a database GUI. Main target was to make it modern and functionality oriented. To achieve these targets, we wanted to use advanced programming environment and tools.

Code was progressing pretty fast despite some difficulties in the specification phase.

Testing had started since some time. Programmers decision was to work with Firefox and Chrome for the validation. The assumptions behind where 2:

1. testing on these 2 browsers would have ensured compatibility with other programs of that kind
2. People would have had the chance of working with these 2 browsers as per their preference.

Then we discovered in a quite dramatic session that:

A. The company had a very old default browser (Internet Explorer 6) and did not allow officially the use of any of the other 2
B. Performances with IE where horribly poor

It was immediately clear to me that the failure was not to make the two assumptions explicitly visible so to start actions to verify them.

This endangered the project success and the fact I found a technical workaround enabling good performances, does not make the feeling of risking to fail better.

Lesson learnt: always make  assumptions, technical or project related, visible. Checking them is the only way to mitigate the risk to fail at a late state...

Engineering of PowerPoint

Very often, from the beginning of my career, I used PowerPoint and its relatives Word and Excel.

While the last two have a quite clear purpose, PowerPoint is the tool with the largest freedom. It is open to personal creativity and gives unexpected flexibility.

Surprisingly, in the engineering field, PowerPoint is one of the most widely used tool for communication both upwards to management and downwards towards team members. The surprise comes from the historical view of engineering as a quite boring and only numbers oriented activity. Flexibility has not always walked together with equations...

But perhaps here is the trick: the misunderstanding is that engineering is not static, but always moving. That's why only a tool where limits are given not even from the page borders is the valid support for idea communication. Presenting is of course not only matter of a good PowerPoint, but the latter is helping to concentrate messages.

Therefore the PowerPoint engineering is nowadays an almost full time job: knowing the tool is the first step. Bending it to the engineering needs the final target...

Processing the processes

Organisations characterise also on the use and abuse of Processes. While some tend to prefer quick (and sometimes dirty) execution, others put a strong accent on the tools and coding of rigorous procedures...

In my working career I made experience of both, finding out the reasonable balance is very hard to be achieved. Of course when you are under pressure for example in a field test, thinking about having a process for changing settings that involves more than simply a couple of clicks, cannot work. On the other hand, in a long term R&D, you should avoid making fundamental decisions without a significant consultation.

Is there an optimum valid for all the cases? I am of the opinion that optimum can only be driven by common sense and self criticism: re-assessing the effectiveness of a process and of its approach should be a cyclic exercise. If it is detected it is quick, but it is causing too many failures, some more intelligent checks shall be applied. In the opposite direction, if a process is slowing down critical executions, the risk of mistakes must be mitigated perhaps with more frequent but less time consuming analysis of specific relevant parameters...

Coming then from the opposite directions, the tendency I would see is to avoid falling in love with what has been implemented. It is rather worth to have a process able to monitor the other processes where the result is simply: OK or NOT OK.

From there the medicine can be drops of creativity, pills of rigour and a constant use of common sense...

There's not just another Blog (on project management)...

Everybody has significant and special experiences that are sometimes worth to be shared at least to make others feel not alone...

I am always astonished how interesting is to read about people real cases and how much you can learn from those. I do not aim to be special with this blog. I rather think there is always a good reason to compare opinions on problems that are solved or not, looking for alternatives.

Is this the major strength of a social approach to work and is my ambitious target not only to report real cases extracted from my daily life as Project Manager, but also discuss and collect ideas from others on how the issues could be solved differently and why.

Maybe one day this could become a little set of helpful hints or starting point to approach different situations...

Names and people change, but histories have often commonalities...