Practical Project Insights

Every project team uses some reporting tool for reporting progress of their work. Conventionally status or progress reporting on projects is done on weekly basis but the reporting format can be used for any periodic interval. As most commonly used weekly report is known as WSR, which is a weekly status report (normally) submitted every Friday but there is no fixed rule. The PM and PMO receives/ chase and compile a consolidated weekly status report for the project as a whole covering relevant points from individual status reports. This is an effective way of reporting a comprehensive state of affairs of a project undertaken during a reporting period. This report is circulated to all relevant stakeholders so as to keep them abreast of the project situation. Normally each team lead within a project compiles status report on behalf of their functional/technical team and submits it to the Project Manager. There are many forms and formats which are used by PM/PMO as per their convenience and relevance, so its ok as long as it serves the purpose of meaningful communication of project facts and status information.

Of many conventional or otherwise reporting format I came across during my professional project management experience, I especially became fond of the ABCD reporting, for the reason of its simplicity (easy to write/read and present). We were used to this kind of reporting on a large, strategic IT implementation project in the APAC region, where I worked as a functional specialist. Its very effective reporting tool where bulleted information in four quadrants presented clockwise on a one slide power point or a one pager word document whatever is preferred, in an easily readable format.

ABCD report stands to report four important aspects, and elicits progress information from the team on these 4 aspects, so this is Output-Input-Output relationship of information where its an Output from team member, Input to the PM/PMO and Output to the stakeholders.

In the analogy of ABCD:

                                                                        A is for 'Achievements'

                                                                        B is for 'Benefits'

                                                                        C is for 'Concerns'

                                                                        D is for 'Do Next'

The report is presented in four quadrant format, a sample can be:

Rules for writing ABCD Report:

General rules:

1.  Mention the name of the project in prominent font

2. Present customer and performing organisation's logo

3. Mention the date of reporting in the document header in prominent font

4. Keep the format need dont use too many colours and cluttering in the format, keep the same font

5. Mention the Submitting Team's  name under project team (i.e testing  team, Development team etc.)

6. Mention the period from -to of which reporting is submitted

7. Keep summary and concise information under bullet points in each quadrant, not very subjective information to be given here

8. Golden rule to follow: Try to finish within a page only.

Specific information in the quadrants:

In the preface to the four quadrant reporting, it must be clarified that the information in these quadrants is related to each other, such as, an achievement shall be causing a benefit, it might have a caused a concern while achieving something, and Do next stores something which will cause achievement in the next period so there is a close nexus among all the quadrants and this forms a chain of relational actions and counter actions which can be analysed and reviewed in order to gauge progress of a project over a period of time. Following paragraphs explains information to be complied in each quadrant.  

A. Achievements:

1. Highlight achievements (in the reporting period)

2. Avoid using ongoing/ working on stuff, rather mention what exactly accomplished. This quadrant must mention your accomplishments only, avoid using exaggeration.

3. Always quantify and clearly state how much has been accomplished. Suppose development team has been assigned to write a lengthy program which will take a few weeks, but it must have something done in this week than to simply saying working on.... For example, this can be reported that 25% of the given code has been finished, or the team has worked out 5 of 10 sub  routines of the main program etc. The reader (stakeholders) will appreciate this kind of information, or if the PMO needs to consolidate total performance of multiple teams working on a project, it would be easy for him to quantify the status for further reporting. This is always helpful in monitoring progress of a task or deliverables.

4. The work which has taken time and could not be precisely quantified must be waited until something meaningful be deduced

B. Benefits:

1. A substance in the fact must be presented, avoid bluffing or boasting

2. A benefit can be, please be critical of your assessment before citing, it may boost or cause a dent to your credibility  -

• Saving in time, cost or

• Value addition without loss of extra time or cost, or

• Adherence to schedule will lead to delivery in time, or

• Increased efficiency in coding will lead to more time in testing so as to avoid future issues/bugs etc.

C. Concerns:

It is very important to list your concerns because they lead to early detections of the potential project problems/risk areas, if not treated might cause a negative impact on the project. This quadrant will be very closely looked into by the Project Manager. Following are the key aspects of writing concerns:

1. Bring up the issues/causes of worries with facts and figures, because un-necessary reported issues/ concerns will depict a casual outlook and may lead to ignorance of real concerns in the future. Below mentioned concern areas are worth of a mention:

• Lagging on schedule, if any thing causing a delay in meeting the scheduled time lines must be listed here

• Areas where you might need support in terms of more human resources, better equipments/servers or some training need

• Performance issue of a team member/ personal conflict among team members or any other area where escalation is needed

2. Try to avoid bringing personal issues/biases under the concern areas, concerns must be related with Schedule, Cost, Quality and Team Management or any visible risk related to project activities.

3. There must be an element of insight, mere perception will be a waste of the team's effort.

4. Have your facts clear in order to convey the real picture in your one on one discussion

D. Do Next:

This area is clearly your work plan for the next week, fortnight or month whatever be the reporting period. Here you describe you plan and lay out activities to follow, in order to enlighten you reviewer of your engagement. Precisely planned activity reported in the status report under this quadrant, will provide visibility and transparency of your future tasks. You may include following subject matter under this quadrant:

1. Catch up work which needs to accomplish some urgent delivery

2. Mention your scheduled task

Triple O Meetings and ABCD Reporting:

Triple O (One On One) meetings are meeting between the project manager and the individual team, which is a normal practice to discuss and understand achievements and concerns so that achievements can be appreciated and the concerns can be addressed appropriately.  The time and frequency of the one on one meeting is as per the requirement of a given project, but ideally it should be every week after submission of the ABCD reporting. This improves overall progress of a project by timely deciphering the issues followed by appropriate actions and maintain focus of the team on project tasks.

Conclusion:

A conscious follow up on timely and accurately preparation/submission and review of the ABCD report as a progress monitoring tool helps the project in securing documented evidence of the progressive work, issues and visible benefits. This becomes an important project document and might be referred to in future for team performance appraisal, issue management etc. Looking at the simple and effective formats, this reporting tool has a potential of formalising into a popular reporting tool in project management practice in the future

Preface

Through the rough and tumble of a project, when all the hardworking on solution design, Integration and  testing is done, QA has satisfactorily passed the results, the time comes to setting the product or result of the project into real life use. The real life has never been tested for this unique work so there shall be challenges and issues. To make sure that transition from the DBT (Design, Build and test) stage to real life happens as smooth as possible, a project needs a cutover process. Though PMBOK doesn't elaborate much on the subject, but refer to transition as an output of the 'Close Project or Phase' process group, as Final Product, Service, or Result Transition.

Cutover is vital process as it involves placing the product or service or result of a project to its operating lifecycle, so that initial issues/pitfalls could be monitored, minimized and managed effectively, thus in context of Project Management it is important to understand the 'Cutover Process'.

Definition

Cutover process involves a series of steps need to be planned, executed and monitored in order to make the project golive. It encompass Cutover Strategy, Cutover Plan, The Cutover Date, Agile Monitoring of the cutover activities and Controlling undesired variations. Its a crucial process and sets focus of the project on important activities which are necessary to make project result for actual use by the end user.

'Cutover' as defined -'rapid transition from one phase of a business enterprise or project to another'. It follows approaches that are emanated from various project experiences and aligned with the organisational policies and procedures for better execution and control. In simple terms, when a project or product completes a development stage, it needs to transit into operations stage or another phase.

Though cutover process is more associated with or pertinent to the IT processes, but it is equally relevant in all types of products/projects, the scale and volume of activities may vary.

For example, rolling out a designed and tested ERP application, a well laid out Cutover process needs to perform in order for the system to work uninterruptedly from the date of its going live, similarly, for rolling out a new train service between two stations also need cutover planning and execution but the activities and steps might be different than the ERP project, same can apply for any infrastructure project etc.

Why do we need to 'Cutover'?

This is very relevant to know why do we need cutover? We have following key aspect of a Cutover Process:

1. Migration from the development cycle where transition of the product/service from the controlled, cockpit kind of environment to real operating environment needs to happen.

2. Establishing or finalising a predefined cutover date from where onwards, new operating procedures/processes comes into effect.

3. The product/service standard operating procedures are going to be changed from the previously used methods/steps and operating instructions these must be prepared and put to use, so 'Cutover' entails user trainings, Handholding and Post Live issue handling procedures.

4. Where it is legally required to follow some different rules after a given date so as to ensure compliance, for example, Govt. brings in law to implement GST instead of VAT w.e.f. 01/04/2017, this becomes imposing date for all the organisations to adopt GST from this date, so this becomes natural Cut Over date for all the organisation to follow.

5. Where support of a product/service is obsolete after a certain date, the obsolete product service must be replaced cutover needs for implementing the new product/service.

6. So that product support function can be activated to support the project during its life cycle

    

   New Product Launches, New Service Launches, New Market Launches, New Software Implementation, Replacing Old system with New improved system, all involves cut over process in order to enter to the real life it a well planned approach so that the transition becomes smooth.

Following are pre-requisites which must be met in order to cutover:

1. All the customer requirements have been incorporated into product or service design and all change requests have been implemented.

2. Testing of the product or service has been completed to the satisfaction of the appropriate team of the customer , as per the acceptance criteriaset up in the Validate Scope process

3. Quality Audit by competent expert(s) have been satisfactorily carried out and their results have been considered by the customer

4. Pre production mock drill have been carried out by the project team along with the customer core team

5. Trainings to the end users of the customer have been completed

6. Any other completions or conformance criteria set out in the SOW or Contract has been vouched and confirmed by the customer

7. All the documentation for use of the new product/service/result is ready in the form of technical documentation as well as the user manual which can be used as a ready reference to any issue faced during the post go live stage.

8. All the Go-Live critical issues have been resolved and their resolution is documented to assist in future recurrence.

9. All legal formalities such as Government Clearances/License fees/ Taxation has been properly dealt with.

The cutover process:

The Cutover process includes strategy, planning, execution and monitoring and control, the whole process is elaborated in following paragraphs:

1. Cutover Strategy

Cutover strategy is the core guiding principle of the organisation, which requires certain organisational objectives to be achieved by putting up the outcome of a project for end use. The cutover strategy is set out in the Initiating phase and developed an insight by project planning phase. It is revisited and revised and finalised  before the cutover plan is worked out.  Cutover strategy provides critical facts which aligns organisational activities to the objectives relevant to project rollout.

Key aspects of a cutover strategy are:

1. Timing and market conditions or other environmental aspects necessary in order to place the product/service or result to end use

2. Determining the need and assess the requirement with respect to Blackout period and devise clear guidance to the project team

3. Requirements with respect to organisational preparedness and orientation in terms of competencies and resource availability

4. Ensuring alignment of cutover plan to organisational objectives

5. Setting up the Organisational Communication in order to clearly defined roles/responsibilities and accountability

2. Cutover plan: All rigor of a project goes into creating a product, service or a result. The time when we have completed the execution of the project activity, all testing of the product or service with respect to Customer Requirement and Product Characteristics and Project Quality is completed and this product/service or the result is to ready to be launched for commercial purposes, we need to roll out to a step called Cut Over planning.  For every project the cutover requirements differs as per the requirements or the nature of the product and the project, but the procedure of the cutover remains generic. In a typical project plan the cutover date is set up based on the baseline scope/schedule dates. So the cutover planning begins with the original project plan and it is essentially elaborated at a later date when project execution is in the last of its leg. Normally detailed cutover planning is started at around 2-3 months before the date of the rollout date depending upon the size and complexity of the project.

The cutover plan needs to be well laid out and needs to be elaborated enough not to leave anything to speculation because cutover involves phasing out the old product/service/result or setting out new product or service as the case may be, so as to minimize on the issues of post go live. Cutover plan, as a sub component of main project plan needs to incorporate following actions:

1. Planning of the availability of Hardware/Software and other material resources and people necessary for the rollout

2. Declaration of Going Live and other subsidiary communications as per the communication management plan from the executives to relevant user group, its timing and content

3. Setting up issue management protocol, alignment of organisational functions with the new requirements

4. Determining Blackout period in alignment with the Cutover Strategy and layout dos and don'ts during this period.

    

   Blackout Period: It is important step to roll out a new product/service or the result that we need to create some space in the ongoing environment of the existing product/service or result so that new product/ service or result can be placed before start. The context of this step is known as 'Blackout Period' where in the current product/service or business as a whole needs to be stopped for predefined period of time  in order to roll out the new product/service or result.

    

   It is important to differentiate among the IT objects/software products, physical product rollout such as a good, machine or other material or an infrastructure such as a road or bridge or a building or a new service such as mobile phone service or rolling out a chain of super stores etc. where concept of blackout to be appropriately modified

    

5. Setting up focused core group for monitoring and controlling variations from the transition process and technical and functional support teams

6. Setting up key success criteria to help measure the success/completion

7. Risk reassessment and devising a fallback plan in case of unforeseeneventuality

It is the responsibility of the project manager to ensure adherence to the cutover plan once it is approved by the project sponsor or the steering committee.

3. Cutover  Procedure

Cutover procedure involves series of activities that are  carried out in adherence to the cutover plan. This the execution of Cutover Plan and  needs active participation from senior management.

Cut over procedure entails below mentioned steps:

1. Freezing Cutover date- Once the product or result is ready, planned cutover date or new date is finalized at an appropriateforum

2. Formulating Cutover Strategy and communication to relevant stakeholders

3. Detailed Cutover Plan and communication to relevant stakeholders

4. Ensuring all steps defined for validation of the deliverables have been achieved and any of parked issues to be taken up after going live have been acknowledged and documented

5. Orientation of the Project Team and The Core User Group for better execution has been ensured

6. Detailed procedure of events and tasks to be carried out in blackout days (if any) and allow for suspension of activities to adapt to the procedure take place with stop, look and go strategy.

7. Big bang opening of the first output of the new product/process recording and acknowledging the start of new process or product life cycle and communication of the success in order to carry the positive message and boost themorale of the teams involved

8. Monitoring and Controlling of the Execution of the Cutover activities

9. Announce the completion of cutover activities and sending out success stories and developing lessons learnt documentation

4. Successful go live and post live support

Once the cutover procedure is executed and the product/service or result went live, all the initial issues have been settled and user has started working on new procedures, the project Go-Live happens to be successful. Now the post Go-Live support is crucial for some time lets say for a month in order to stabilize the new process and hand over completely to the operations teams. After successful go live, product  support is taken over by the specialised support team to support the ongoing operations. On successful transition, appropriate management communication must be issued to all relevant stakeholders so that the project team can proceed with other Project Closing activities.

Conclusion:

A strong cutover strategy followed by a well defined cutover plan is indicator of success in transiting the product/service/ result into real life. It ensures  issues are minimized and controlled, operating becomes easy and a speedy recovery of costs and ROI. A diligent planning ensures that all steps/activities required for transition has been taken into account and uncertainties has been duly accounted. All risks have been duly noted and response plans are weighed and appropriately adjusted.  While we execute the cut over procedure the care must be taken to adhere to the plan and any deviations noticed must be duly communicated to the relevant stakeholders in order to take any corrective steps as required. An active participation by senior management is imperative for success of a cutover process.