Its the last labor of your love to close a project!
A seemingly end of a cycle has a potential of a new beginning, this is important for the organizations rendering professional services for clients as well as internal project organizations from the stand point of enablement of the teams who are going to take care of the product of the project during its operational lifecycle, so its all important to close a project formally. As projects by their very nature are temporary endeavors, so when all the deliverables having delivered, the product of the project has been put into operations, the project is technically complete. But there are several practical tasks which are formally needed to be carried out in order to close a project.This post aims at sharing knowledge about the tasks involved.
As PMBOK® lays out, a project needs to be closed, if:
A. Project has come to close after completing its normal cycle. Or there are circumstances that;
whatever may be the case, the Project Manager needs to accomplish this task diligently so that-
1. Value can be demonstrated through accomplishments of the project
2. All legal contracts could be wound up
3. Setting up procedure for warranties and AMC
4. If it is a phase closure then, preparation for next phase can be started
5. Knowledge in the form of Organizational Process Assets can be preserved through archival of project documents, which can be retrieved for reuse in the future
6. Lessons learnt can be recorded and preserved for future reference
A project closure goes through an essential Handover/ Takeover process, where requisite knowledge is passed on to the client IT or Centre of Competence for carrying out the support during the operational cycle.
Following is the closure process:
1. Handover Project Documentation: On a typical IT/ Software Implementation project, the project manager is required to pass on the technical/functional documentation to the client, before the client signs off the formal closure document of the project, signing of this document is important to get the acknowledgement from the client and it can help the implementer establish their claim to any money pending to be paid for such milestone.
These technical documents are:
2. Program specifications for custom developments/ code enhancements etc.: both functional as well as technical documentation ( this may be subject to any specific agreement between the parties or may be subject to any intellectual property rights stipulations)
3. If the agreement provides so, instruction manuals or business process documentations
4. Standard Operating Procedure documents for handling special business requirements
5. Configuration documentation for technical systems set up, as applicable
6. Handing over the issue log, issue resolution information to the CoC team of the client
Above documentation is a part of hand over process, and constitutes a value delivery to the implemented processes, product or service so that operation is carried out smoothly and scalable solutions are incorporate in future.
2. Release the project team: Project closure entails the project team members are released of their project responsibilities and are appraised of their performance by recording the same in the appraisal system. For the outsourced employees, their staffers must be communicated their last working day in advance so that their agreement can be appropriately closed.
3. Closure of Contracts: Entered into with various parties for renting of equipment, facilities and time and material contracts for contract workmanship, needs to closed and warranty/AMC information needed for supporting any equipment/servicing must be passed on to the incumbent teams for better managing the operational life cycle.
4. Compiling lessons learnt documentation and providing it to respective PMO for record keeping. A project manager must avoid cluttering and unnecessary information pile-up and guide the team to keep crisp and objective statement of lessons learnt in an easily phrase able language.
5. Archive Project documents: Project documents include, technical and functional documentation, program codes, configuration information, cost estimates, assumptions and project budget, Risk documentation, etc. Easy retrieval of these reference documentation is the key to their archival, its always good to maintain a directory of the project documents.
6. Sign off of project closure, by securing approvals from the steering committee/sponsor of the project, on a duly compiled formal Project Closure document.
7. Finally sending out the project closure communication to all the relevant stakeholders, so that the fact of project closure is formally disseminated to all relevant parties.
A well closed project ensures a repeat business for the professional services rendering organizations, and a ensures effectiveness of the internal organization as the case may be, so it must carried out with rigor and professional diligence.
'Activate' is new SAP Implementation methodology
For long the fable 'ASAP' roadmap was a synonym for SAP project implementation, but with the advent of more powerful modular solution delivery through enhancement packs & business functions and exceptional in memory DATA calculating platform S/4 HANA has migrated from ASAP methodology (a traditional WATERFALL method of project implementation) to an improved 'ACIVATE' methodology (Agile method of project implementation)of software implementation.
The previously used methodology of ASAP is no longer updated by SAP.
SAP now recommends to implement projects using 'ACIVATE'
SAP Activate Methodology is a modular and agile framework for implementation or migration of SAP solutions that provides content and guidance for project teams. It supports project teams through all stages of your project, from initial planning, through requirements implementation, to the on-going improvement of your SAP solution. There are two variants of ACTIVATE methodology:
1. SAP Activate Methodology for cloud solution
2. SAP Activate Methodology for on-premise solutions
1. SAP Activate Methodology for cloud solution: Activate Methodology for Cloud provides an implementation framework to support subscription based software where the system installation and management occur outside of the project (SaaS). Self explanatory four steps (PERD) are:
SAP Activate Methodology for on-premise solutions:
The SAP Activate methodology for on-premise solutions is designed to support project teams in the new implementation of SAP solutions in on-premise deployment model. Self explanatory five steps (PERDR) are:
The 'ACTIVATE' methodology is structured into project phases and work streams that contain deliverables and supporting tasks.
Solution specific accelerators improve efficiencies by providing the project team with the tools necessary to get the job done. SAP Activate Methodology for Cloud is lighter weight than a traditional project making it ideal for smaller project teams. It is easily integrated with larger on premise projects to create a hybrid implementation approach with a single overarching methodology.
Why I chose the subject title as Demystifying ROI? What is there in it to demystify?
Return on Investment is a widely used tool in assessing the performance of money spent on projects by the executive management. PMO or Project Managers in their capacity has to supplement information or go across using the concept of ROI in some way or the other. The concept of ROI involves complicated financial jargon such as IRR or hurdle rate, Net Present Value, Cost Of Investment, Return etc., which is quite difficult for a non finance manager to understand, hence the financial terminology needs clarification/simplification for ease of use of the non financial managers/ project managers.
An appropriate understanding of concepts involved in ROI process by a Project Manager or PMO helps them: Winning projects by calculating and projecting ROI appropriately; ROI as a tool offers tremendous capabilities for comparison among projects so it enhances financial visibility and decision making of PMO.
I had picked up the best of explanations from the available knowledge resources on ROI, mixed them with my practical experience, and tried my best to present a simplified reading through this article.
Defining the term ROI
Let's analyse a few definitions.
According to investopedia Return On Investment is: "a performance measure used to evaluate the efficiency of an investment".
isixsigma defines the ROI as:
"ROI is an indicator used to measure the financial gain/loss (or “value”) of a project in relation to its cost. Typically, it is used in determining whether a project will yield a positive payback and have value for the business."
Terms used in these definitions of ROI entail a lots of confusion which are explained/clarified in the later part of this article, these are-Payback, Payback Period, Financial gain/loss, Efficiency of an investment, Cost and Value for business.
In context of a project, ROI is a measure which is used to gauge efficiency or effectiveness of your investment in a project. Monetised value of quantified future benefits is calculated and compared with a normally expected rate of return, which gives you a result which is either positive or negative and used for decision making for about go or not go for a project, this sums up the whole ROI calculation process. ROI as an indicator of gains (return-cost) over your investment generally expressed in terms of % or is presented as a ratio.
(Return- Cost of Investment)
Cost of Investment
Where, Return: A sum on money received in terms of increased revenue or cost savings
Cost Of Investment: Money spent on project ( inclusive of the direct/indirect expenses, cost of implementation, cost of hardware, cost of software etc.) In context of a project, there is going to be spending of which the return will start coming after elapse of time so it is important to know when the venture has recovered the cost and started producing profits.
PMBOK® asserts that, in many projects predicting and analysing the prospective financial performance of the projects' product is performed outside of the project, but for other projects such as capital facilities projects, ROI calculation becomes part of the plan cost management knowledge area under planning process group, thus importance of ROI as a tool as been acknowledged here.
Yes, let's get it done here!
As the concept of ROI is complicated and is subjective to the area of application such as an IT infra project, ERP Implementation, Capital Investment Project in manufacturing etc., it's imperative to clarify and explain the terms and methodologies for ease of use in project management environment.
First demystifying idea is about the basis of calculation, i.e financial gains/profit vs cash, there is a lots of confusion about the concept of return, some consider the profit which appears on the profit and loss statement of an organisation to be return. But prudent practice would be cash not the profit, because the expenditure incurred on the project are cash spent so this must be compared with the incoming cash to be an appropriate comparison. Harvard Business Review advocates an ROI calculation based on capacity/incurrence of inward cash flow as a benefit from the product of the project received by the organisation during the expected period of realisation.
Efficiency of investment connotes a criteria that explains how much more beneficial an investment in a project is from the other(s). This can be evaluated in totality as well periodic value of ROI. As the ROI connects project performance with the business objectives it proves beneficial to the management in avoiding investment in projects which are not worthy to the business.
The process of calculation of ROI involves four generic steps in calculation of the ROI, as has been explained in an Harvard Business Review article by Joe Knight:
This process is generic and can be used in calculating ROI in any context, for purposes of this article project specific calculations and elaborations have been considered.
First step in determining the ROI is the calculating capital outlay, which means how much of money need to be spent in order to implement a project. Cost of Investment or in a typical IT environment its known as TCO ( Total Cost of Ownership), which consists of all Direct Costs- Costs which are specifically spent on project by acquiring equipments or other resources to be engaged on the project exclusively and Indirect Costs, which are share of overheads from general services such as Finance and Accounts, Shared Infra such as Phone and Internet etc. which are not specifically installed for the project but the project uses these facilities so a charge is essential on the project costs. For example sake, let's examine components of cost of investment:
*Remember costs are cash outlays and must therefore be compared in terms of prospective cash inlays so as to calculate the ROI.
Second step is forecasting cash from the investment which is often known as benefits, this is the toughest most aspect of ROI determination. Benefits in totality constitutes the Business Value which comprises of Tangible as well Intangible benefits, but for ROI calculation purposes only tangible benefits (which can be computed in incoming cash to the organisation) are considered. The benefit types are explained here below:
Tangible benefits- where benefits of the project can be measured in clear financial terms. These are:
A. Future savings in the Costs- Comparative costs of operations before and after implementation of the project and these can be categorised into:
IT Labour/Services TCO Savings- Savings in number of Error Instances, Number of machine breakdowns etc. which can be directly quantified in financial terms.
Other Direct Cost Savings
User Productivity Benefits- Saving in terms of labour rate applied to number of transaction processed before and after the project implementation.
B. Future incremental revenues- Growth in the revenue in comparison with the numbers before and after project implementation offers easily measurable benefits. These can be categorised into:
Revenue Growth- by handling more number of sales orders, this can be computed by number of sales orders processed in AS-IS and number of sales order processed in TO-BE
Intangible Benefits- these are variables which can't be quantified in direct relationship with a project but essentially contributes towards future benefits such as:
Growth in market capitalisation by incrementing share prices
Incremental Goodwill/ Business value
Third step is determining IRR (Internal Rate Of Return) or Hurdle Rate, this is the minimum expected return which the stakeholders would expect their investment to fetch. There are many factors which impact the IRR such as market prevailing interest rates, opportunity costs of investing in other instruments/projects, Cost of Capital and the Risk involved in the project etc. Finance department or CFO'S office would not like sanctioning funds for any such project which is fetching future benefits below IRR. So IRR is very important threshold value for determination of ROI.
Fourth step is to Evaluate your investment, there are 4 parameters to evaluate your investment by ROI calculation and analysis. These parameters are Payback, Net Present Value or NPV, The Payback Period and Internal Rate of Return or IRR.
Here Payback equals to cost of investment and ROI calculation establishes how soon the investment made in any project be recovered. This period of recovery is known as Payback Period. The payback period of a given investment or project is an important determinant of whether to undertake the project, as longer payback periods are typically not desirable for investment. Any unit such a month or a year can be considered for denoting the payback period, whatever you choose must facilitate your internal reporting and information consideration of the management. Internal Rate of Return, is the benchmark figure on which the calculated periodic ROI is compared in order to find if the project is fetching over or under the internally expected return. IRR is periodic rate and thus facilitates a more even comparison of the benefit.
Net Present Value is the present value of future cash benefits after considering a discounted rate for reducing effects of inflation and erosion of monetary value of the benefit.
Evaluation of investment process:
1. Some managements are interested in the Payback in terms of money spent in simple terms, profitability of project benefits thereafter is considered as a part of normal operations gains/loss. The time value of money/Opportunity costs are not taken into account in calculating ROI using Payback method. So its a simple bland way of judging how soon your costs will be recovered from the date of the project implemented, and doesn't offer too much to facilitate decision making, this method is mostly suitable to in-house technology upgrade and maintenance projects which are not driven by strategy or long term plan. Also the fact that the investment will continue to bring benefits even after the payback period is ignored by payback method, which doesn't give true picture of real gains can be fetched by the project.
2. Some companies are more concerned about return on investment for total period of their holdings, so they shall be interested in knowing the gains over this period. There applies the criteria of calculating net gains from the revenue achieved which is enough to recover the payback plus minimum expected return (IRR), the investor would be very happy receive anything over and above this
3. To perfect the analysis and determination of return in true financial terms, it is important to consider the Net Present Value of future cash benefits. In an inflationary economy, money erodes its value over a period of time, suppose we are calculating Return for over a 5 years period in today's date, we must consider deduction from this sum on account of inflation, to come about to a real figure for comparison of current investment value of money.
4. Further step to ROI calculation and evaluation of investment is comparison of the return with the IRR, the management is not interested to spend on projects which do not have a potential of earning less than the expected internal rate of return.
Limitations of ROI:
One must be careful in their assessment of ROI for their projects as it has certain limitations, firstly if the payback period is not considered then the ROI decision might lead to erroneous conclusions. Best way to analyse ROI is to divide total ROI with the number of periods it will take to arrive, this will give you a periodic ROI which is easier to compare with the IRR. Project with a higher period ROI will be selected over another because it will take lesser periods of time to arrive at desired return.
Secondly, certain criteria in quantifying the benefits are subjective the situation and nature of the business, hence the people involved in the calculation process must acknowledge the complexity and situational variables so as to arrive at a best result. Anyone responsible with the calculation of ROI, should be cautious of not exaggerating benefit calculation.
A speedy recovery of their investments is the top priority of the management, and when you start having a positive return that is a great deal of an accomplishment. As the ROI happens to be the key criteria of project selection hence it is very keenly followed up by the management, any negatives on this count has a potential to kill future prospects of the performing organisation, whereas a positive and early ROI can help achieving best of a credential and a future reference for a PMO. The project management team must be helping the management to highlight the key benefit areas appropriately correlating this to the monetary calculations and tying it with Business Objectives, a determination of an appropriate ROI and payback period helps projects securing stakeholder buy-ins contributing to a health project organisation.
I have given utmost attention to un-complicate the whole process involved in ROI, but still in case you feel that the subject needs further elaboration/ clarification, please do write to me email@example.com I shall get back with the relevant clarification/explanation.
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:
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.
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
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 -
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:
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.
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
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'.
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:
Following are pre-requisites which must be met in order to cutover:
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:
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:
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:
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.
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.