When I read Tim Ingram-Smith’s post on PMHUT, I tried to match his experience gained on external customers’ projects with mine in internal information technology projects.
In fact, the colleague to colleague relationships between computer specialists and business users within the same company instead of a customer-supplier relationship between two companies does change the situation but may be not as much as one could think at first sight.
The most successful programmes on which I worked had very clear, documented written objectives and strong commitment of the top management.
It was for example the case during the Implementation of an Enterprise Resource Planning (ERP) software package globally in 18 months at a large multinational company. The director of the program (for which I ran the PMO) made sure of the clarity of the objectives by documenting them and having them signed off by the executive committee of the program and by his sponsor, the Chief Financial Officer of the company.
This initialization of the program was critical to our success:
- It provided a clear scope,
- agreed and measurable objectives,
- defined and endorsed means for internal and external resources, and
- commitments to assistance to proper change management by key executives.
This ERP deployment program also contained a wide ranging organizational optimization aspect and standardization of processes accompanied by functional reshaping of the finance departments. All financial processes which were redefined by the team project were manually signed by the people in charge of these operational functions in the company (countries and regions financial controllers; responsible for accounts department, for the invoicing, the purchases…).
A manual signature reflects in my opinion a much stronger commitment than an email approval very much the same as paying in cash is a more cautious/conscious spend than an electronic payment.
Personally, before signing manually a document, I read it in a very attentive manner. I may even ask a domain expert on the team to verify ome of its technical contents. Therefore, my personal feeling remains that a manual signature has more value than an electronic one. I realize that it may be an incorrect perception since nowadays a simple SMS can be used as proof in front of a court, but I am certainly not the only one to be a victim of this perception. An in Project Management, perception is often king. Will it change with the generation Y that was born with Internet and mobile communications? What is your own personal opinion?
As Tim mentions in his article, the temptations are numerous to start without formal sign-off.
We also experience these on internal projects, notably the excuse of critical due dates, pressure from management and colleagues, and fear to leave some employees idle:
1. Compulsory timeframes: always a bad reason!
“Any solution proposal which cannot be ready by January 1st is of no interest to us!”. I witnessed and I admit I was also a stakeholder of numerous decisions where the choice of solutions was based mainly on the projected delivery date. Often, other components would have better met the needs businesses but seemed to take too long to build.
In computing, a typical example is to try by all means to reuse an application developed in a group for a precise purpose in other circumstances and for other objectives. “This application works perfectly in Europe, there is no reason why it shouldn’t work in Asia where we sell the same products and services”.
Indeed, it appears logical and attractive: less development and testing, skills availability, speed to get the solution …
Regrettably, the time required to tailor the solution to the new context is very often vastly under-estimated and, furthermore, the adequacy of the solution to the needs of its future users widely over-estimated with a limited consideration of context, work practices, and cultural differences. It often results in a high dissatisfaction of the new users and, at the end of the day, a launch date close to other solutions we could have selected if we stopped the sole focus on projected delivery time.
Even when these pressures come from sincere convictions of the persons who support their "best solution", they often result from a partial understanding of the situation and of the full objectives of the project.
They are also tinged with considerations more down-to-earth such as availability of the skills required for each solution, internal power play, desire to develop new skills in a department, allocation of resources at the level of the projects portfolio.
We cannot ignore them, but they do shouldn’t biases our vision and take us away from agreed selection criteria for the best solution for our project.
3. Available resources.
Another element than Tim mentions in his article and which is very important: the imperious desire to use available and unoccupied resources is very strong and somewhat justifiable from the point of view of the management of the company.
But, from the point of view of the project:
- Do these resources have the required skills?
- If not, how long will it take to develop them and is it even feasible?
- If they are available and have the skills, is it a sufficient reason to start without formal approval of the project?
My experience here is mixed.
In fact, if a strong mutual trust exists between business and IT, we can start projects of reasonable size, prototypes, or incremental development without formal signature in an "Agile" development approach.
But, on any big IT project, it is worth securing the approvals of all parties before starting (in Agile or more traditional approaches).
Otherwise, we run the risk of having to undo and then redo (if we still can do so) what could have been done first shot with a better alignment of the project on its objectives.
One of the senior consultants I had the chance to work with used to say: