hand written signatures are antiquated! or maybe not?

the importance of hand written signatures in projects

When I read Tim Ingram-Smith’s post on PMHUT, I tried to compare his experience with external customers’ projects to mine which is on internal information technology projects. In fact, our colleague-to-colleague relationships between computer specialist and the business user working for the same company instead of a customer-supplier relationship between two companies does change slightly the situation but may be not as much as one could believe at first sight.

As far as I can recall, the most successful projects on which I have worked had very clear, documented written objectives and strong commitment of the top management, or they were performed in Agile mode (at times when it was called incremental development). For example, this was 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 (of which I ran the PMO) assured the clarity of the objectives by formally documenting them and having them signed off by the executive program committee and his sponsor, the Chief Financial Officer of the company. This initialization of the program was critical to our success: it provided a clear scope, defined and measurable objectives, agreed and endorsed means to staff the programme with internal and external resources, and commitments to get the support of key executives to the change management process.

This ERP deployment program also carried a wide range of processes standardization and optimization and functional reorganizations of the finance departments, i.e. major changes for the company and its employees. All financial processes that were redefined by the project team were manually signed off by the directors in charge of these operational functions in the company (country and regional financial controllers; accounting department manger, invoicing, purchasing…).

The thing is, a manual signature reflects a much stronger commitment than an email approval. Personally, before signing manually a document, I read it with great attention. I often ask a domain expert on the team to check its technical contents. So, my personal feeling remains that a manual signature has more value than an electronic one. I realize that this is certainly an erroneous perception since nowadays a simple SMS can be used as a valid proof before a judge, but I am certainly not the only one to be a victim of this perception. Will it change with generation Y, who was born with internet and mobile communications? Perhaps.

As Tim mentions in his article, the temptations are numerous to start the project without formal sign-off. We also experience these on internal projects with the usual excuse of critical due dates, pressure from management and colleagues, and fear to leave some employees idling while waiting for sign off:

1. unmovable release date: “Any solution proposal which cannot be ready by January 1st is of no interest to us!” This is always a bad reason. I have been the witness of numerous decisions where the choice of the solution was based mainly on projected delivery date. Other solutions were better fits for the business needs but looked like they would take too long to build. A typical example in IT is to try to bend and reuse an existing application developed for another need. Example: “This application works perfectly in Europe, there is no reason why it wouldn’t work in Asia where we sell the same products and services.” Indeed, this may appear both logical and attractive: less development and testing, skills and knowledge are available, get the solution fast… Regrettably, the time required to tailor the solution to the new context is underestimated and the adequacy of the solution to the needs of its future users widely overestimated. It often results in high dissatisfaction of the new users and a launch date that worse than those of other solutions we could have selected without such an initial focus on time.

2. management and peer pressure. There also, even if these come from sincere convictions of the persons who support their “better solution,” they often come from partial understandings of the situation and of the real objectives of the project. They are also influenced by down-to-earth considerations such as the availability of required skills, internal power play, desire to develop new skills by a department head, resources allocation optimization at the projects portfolio level. We cannot ignore these parameters, but they shouldn’t distort our vision and take us away from the agreed set of selection criteria to build the best solution with our project.

3. resource availability. This is another element than Tim mentions in his article: the strong desire to use available and unused resources is justifiable from a financial management point of view. For the project: Do these resources have the required skills? How long will it take to develop them? Is it feasible? Is it a sufficient reason to start without formal sign off? In fact, when a strong mutual trust exists between business and IT, we can start projects such as prototypes or incremental development without formal signature using an “agile” development mode. But, on any big IT project, it is worth securing the approvals of all parties before starting. One of the senior consultants I had the chance to work with used to say:

“If you do not take the time to do it right the first time, then, tell me when you will take the time to redo it.

"Because, there is no doubt: you will have to redo it!”

photo © Gina Sanders - Fotolia.com