May, 2009

Post Implementation Review – When, ldeally?

When is to perform a post implementation review? A witty answer could be – obviously after implementation. Ha! Definitely a successful closure of implementation could declare a project closure with a formal project acceptance report or project sign off. So shall we have a post implementation review as soon as we have a project sign off? Nah! That would not solve the purpose. Give an appropriate time to the customer team key users to settle down as the captain of the ship and sail it smoothly. One day or one week smooth sailing will not tell you the turmoil or undercurrent storm about to come in future. Correct. Then future is too long. That means keep waiting for turmoil. But mind it, all ships sailing in the sea do not experience storm. Similarly all products after implementation and project sign off do not guarantee a serious disaster.

Product performance in actual sense requires a certain timeframe to establish and to give confidence to end users. Some part of post implementation review related to team performance (implementation) can be answered quickly, maybe immediately after the project closure. But the other part needs a considerable amount of time to understand the product from different perspectives and accordingly present a right picture in the review report.

Certainly, then, atleast a period of minimum three months is required to experience the product and then fill in the post implementation report. Ideally, I would say, wait for six months, use product in all respects, aggressively, and then the top management need to sit with their key users and project board to evaluate, assess and fill the post implementation review.

Post Implementation Review – Why required?

A successful implementation does not ensure the completion of project. The reality starts when the implementation team has gone back and users have started using the project in full swing with the help of training material, learning, knowledge and product. The health of users in respect of using the product is sustained, deteriorated, or improved will depend on many factors. A post implementation review is always important to understand the users understanding, pains and delights during this tenure. This will translate further into management’s pains and delights. The overall delight weightage has to be higher than the pain. In a blow of project implementation phase users might feel quite confident regarding the product features, functionality and ease. When the whole thing falls upon them, it usually drive them in confusion, wrong actions or stoppages. Or a smooth drive.

A post implementation survey will help in a real measurement on two fronts. One front will be users’ understanding, ease and comfort (or vice versa). Second front will be product’s stability, performance and functionality. It also will assess the after effects of a successful project implementation.

The conclusions could be misleading although and will require a deep analysis. A user’s lack of understanding may spell into products inefficiency or the opposite of it.

What is Post Implementation Review?

A Post implementation review is conducted after a substantial period from implementation sign-off. This review is to ascertain customer management’s and users’ experience on product in absence of product implementation team. The product has been implemented successfully and the team is gone. Ofcourse sufficient learning, knowledge, exposure and material have been imparted to users by the implementation team.

Post implementation review by the customer management with key users will spell out – user’s depth in using the product and product’s reliability and stability. The format of post implementation review document should be designed by the vendor management for the purpose of understanding the status of project after a certain period of usage post successful implementation. Filled by customer management in agreement with key users’ experience, the report is sent to vendor for their assessment.

5 reasons of top level customer expectations missing in requirement study document

As stated in previous two blogs, top level expectations gathering is very crucial during the business study and requirement gathering phase. And respectively I mentioned how vendor and customer can be careful (and should be) about that. Although it is rare and unexpected, but there are instances where customer organization top level management may not involve in a new software development project. This could have various reasons but could lead to only a single road – where the end is DISASTER. If this so happens, the chances of project getting hurt are manifold. It will precisely and ultimately lead to project failure. The reasons could be many, but to my mind following come at the top:

1. Customer Top management presumes that their involvement requirement is only for signing agreements, papers, reviews and sign-offs. If that so, they will have almost negligible awareness that how critical it is for them to get their expectations and requirements (top level) during requirement study phase. After all it is an investment of time, resources and money. Instead of getting a jolt at a final stage about getting the unexpected or not getting the expected, it is better to explain right in the beginning their own requirements and expectations from the product in detail.

2. Vendor’s management role is very crucial during this phase. They have to take initiative in explaining the top management about the benefits of the product being proposed. How it is going to enhance the processes in the organization, the change in roles etc.

3. Assume a situation where there is a pressure from user level for a solution or a product at customer end. The management is not sure about the product. Without horizontally analyzing various solutions available, they decide to go for a particular vendor or product just for the sake for fulfilling requirement. Although it will be rare, but even it is there at a very low intensity, it need to be addressed.

4. Customer top level assumes that the solution being invested into is meant only for user level and not organization level. This is a wrong assumption. Any investment – small or large- has to have benefits for the organization and top management on the cards.

5. Customer top management overestimates their users and assume that they will be able to drive the project without top management’s involvement. This does happen but very rarely, in very organized structures.

Customer’s role in business study and requirement gathering phase of a software project

Usually it is the customer top level person who is project sponsor for a software development project, be it in-house or from a software development vendor. A Project Sponsor may presume that his/her roles during the project would be – sign agreement and papers, assign roles down the line for the project, monitor/review project at various stages etc. A critical and crucial role is overlooked that of getting into the project especially during atleast vendor’s business study and requirement gathering stage. It is not only important for project sponsor and directors to be part of this stage but equally important is to involve all top management in that.

In brief, Customer Top management has to fully understand the benefits being proposed by the vendor that will be produced by the software when it is in use. They should also participate fully in business study and requirement gathering meetings to define and freeze their own expectations from the project/product/software/vendor.

Vendor’s role in involving customer top management while requirement gathering phase

The most critical stage in software project lifecycle is business study and requirement gathering. Vendor has to be very cautious and careful in understanding all levels expectations from the product they are going to build for the customer. Skipping top level at this stage could be disastrous for both. As a vendor, if you don’t involve customer top management while gathering requirements – you are inviting a mishap!

Customer top Management involvement is very critical during the business study and requirement gathering phase of a software project. The expectations of top management shall invariably be different as compared to other stakeholders of the software project at customer end. Assuming that the requirements gathering from process owners or end users will be sufficient for developing software will be a misconception. A detailed discussion for capturing requirement and understanding top management perception is critically important to lead to a successful completion of the project.

At the Vendor end – the Project Manager has to ensure that besides capturing user level requirements, it is essential to highlight the benefits to the top management being proposed for them from the product. It is not desirable but mandatory to freeze top level expectations at business study and requirement gathering stage.

How to manage Change Management – in terms of scope of the project

Scope defined and decided upon initially by vendor and customer mutually has a large impact on timeline, progress and success of a project. A change in scope at a later stage may call for a big impact on project schedule and progress. Let us see the roles of vendor and customer respectively in this aspect of project.

Vendor - Project Manager has to ensure that the scope of project defined in the Business Study Document has to be adhered to. Any change in the scope (increase or decrease) has to be escalated to both the managements and the project plan has to be re-designed thereupon.

Customer - The management and project manager has to ensure that they define the Right scope for the project (number of locations, pilot site etc.), also understand that any change in scope will adversely effect the project plan and hence seeks redefinition. The pilot site chosen should be the best possible site in terms of testing the software completely and rigorously.

SIGNificance of Sign-offs at appropriate stages

Sign-off at various stages has a significant importance during project lifecycle. Everyday sign-off can be a headache for customer, no sign-off can cause headache for vendor, so there has to be a balance of sign-offs of milestones, achievements and stages of project so that the sanctity of sign-offs is retained thereby earmarking the progress of project. Both, vendor and customer have to be very careful in this aspect of project management as it is crucial for all stakeholders.

At Vendor side the Project Manager has to educate the customer management and project manager over the benefits of timely sign offs. Sign-off should not be there just for the sake of it. It should add substantial value to the project.

At Customer end the Project Manager and management should respect the timely sign-off practice but also ensuring that the activity which is being signed off has finished in actual, rightfully and rightly.

Two aspects in Change Management in Software Project

Change management is a subset of project management. In any software project change is to be managed during the whole cycle of development and implementation. Requirements once specified by customer at the business requirements study phase does not mean that there will be no change in requirements later. Vendor who is not open to mange or cater to this change in requirements will not be able to deliver the product to customer upto his satisfaction. To mange these changes Change Management is essential and both have to play their respective roles in managing the project. Changes could be in terms of specifications, process being re-defined, or change in business rules. The two aspects for change management are – vendor and customer.

At Vendor level the Project Manager should accept changes only that are business critical and not cosmetic or wishful in nature. He should redefine the project/ development/ implementation plan in terms of time and revenues in consultation with his management taking customer management in confidence. He should incorporate changes only after getting it approved by customer top management.
The Project manager has all rights to challenge any change in requirements that is fanciful, not business critical and is impacting the software largely in terms of efforts and time.

At Customer level the Management and Project team have to understand the impact of any small change on the software thereby asking for a change only if it is a business critical change, analysing if the change can be avoided, and understanding the time and cost effect of the change.

Change Management in terms of people – how to manage during a project

Although it can not be avoided in real life scenario and that is why there is a risk plan and risk management to avoid such circumstances. But still a lot can be done to atleast minimize the risk and thereby mitigation.

Vendor - Management has to ensure the bare minimum changes (preferably NO CHANGES) in terms of project manager and team members during the project lifecycle.
They also have to ensure that the project is handled in such a manner that any change(s) happening therein will not affect or delay any of the stage.

Customer - Management has to ensure the bare minimum changes (preferably NO CHANGES) in terms of project manager and key users during the project lifecycle.
They also have to ensure to adhere to the guidelines specified by vendor project manager to manage such change(s) so that it does not affect or delay the project during any stage of the project.