Five Key Steps to Closing Down the Project

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

A lot of text and attention is given to how to start projects, and how to run projects. But process of properly closing down a project is overlooked. Why? Well, since I can say from experience that I’ve been guilty of this in the past, here are my reasons, at least:

• Implementation and transition to support happened so moving on seems reasonable
• Have 4-5 other projects I’m also managing
• Just received a new, hot project and I’m preparing for kickoff
• Problem-free implementation means no worries, right?

Look at that list…none of them are good excuses for just basically dropping the ball – and the customer – post-deployment. Things still need to happen, proper hand-offs may still need to be taken care of, information needs to be transitioned. It will happen anyway through frantic phone calls and emails, so why not take care of it in an organized fashion? Because we say we’re too busy…but that needs to change.

Here are my list of five key activities that should happen to ensure proper closure of the project you’ve just finished. Your list may differ and I’d love to hear from you if it does. Feel free to comment and share with our readers here on PMTips.

My list:

• Make sure all pertinent documents and deliverables have been signed off by the customer. You don’t want this coming back to you after the project is over – especially if there are any question marks our payments outstanding.
• Get a final signoff on implementation/solution acceptance. You may have the best relationship in the world with your customer, but don’t skip this step.
• Conduct a lessons learned session with the customer and your team. The information you glean from this type of session can be invaluable to you as a project manager going forward, to your customer as they go forth with the implemented solution, and to your tech support as they provide the ongoing support for the solution with the customer.
• Hold a proper handoff to tech support. Make sure they have all necessary information in order to properly support the client post-deployment.
• Keep in touch with the customer post-deployment. You may have a 30 or 60-day agreement to remain available to the customer and for your team to remain available before the formal transition to tech support. But don’t just drop them at that point, keep checking back. It’s good for your reputation with the customer and for your company’s reputation.

Implementation Preparation

As the delivery team plans for deployment, or implementation – depending on what you prefer to call it, there is much preparation that must occur. How you prepare for your particular project depends on several things including the following:

• Customer requirements
• Type of system being implemented
• Policies and processes of your organization
• Logistics of customer, delivery organization, and implementation site

Personally, the type of implementation prep that I go through with my team is dictated heavily by the needs of the specific implementation and what was planned for and laid out as part of the statement of work and the kickoff sessions with the customer.

In his book “Project Management Nation,” Jason Charvat discusses his vision of typical implementation planning and preparation. While I don’t specifically endorse this process and understand that your specific situation usually dictates how implementation is handled, I believe that this is helpful and useful information.

Implementation Checklist

The project manager must be sure that the implementation follows the implementation tasks and activities as stated in the project schedule. This forms the basis against which the implementation will be done. Generally, the tasks would be to:

• Load or install the new system
• Perform a system test
• Convert to the new system
• Verify that an application works with other applications in the system
• Perform an integration test
• Perform an acceptance test

The Implementation Plan

The implementation plan, which was developed by the project manager during the design phase, should, at this stage, be approved and communicated to all project stakeholders. A successful project can be ruined by a poor implementation plan. A working implementation schedule should be developed and maintained for all parties to use and agree upon. As the project changes, the project manager must pay close attention to the schedule and update it to reflect the latest changes to the implementation date. This schedule should then be communicated to all project stakeholders.

It is important to publish an initial implementation schedule for each site early in the project. Many members of the deployment project team will reach a point where they cannot until they know the time, sequence, or date of the implementation. Experience has shown that developing a draft implementation schedule early in the project life, rather than later, resolves many problems. The project manager should remember that the implementation plan could be put on hold if the software development is late for whatever reason. However, if the implementation plan cannot be moved and there is no slack in the schedule, the project manager should immediately escalate this risk to the necessary stakeholders.

Meetings Leading up to Implementation

The implementation plan must be discussed and agreed upon by both the user management and IT support staff in order to ensure that both parties plan their work schedules to match the project schedule. For the majority of IT projects, implementation will most likely occur after hours or over weekends, during a series of working hours per day, or on public holidays.

The Importance of Testing

Any IT solution that is implemented without the proper amount of testing performed throughout the project is a definite recipe for disaster. Testing is an ongoing process – both formally and informally. It happens in development, it happens in the actual testing phase, it happens just prior to deployment and it happens post-deployment.

In his book “Project Management Nation”, Jason Charvat discusses the importance of testing throughout an engagement and identifies the different types of testing that we usually carry out in both informal and formal processes. By sharing this information here, I am not fully endorsing it, however I do find it interesting and likely beneficial to our readers.

The Importance of Testing

Without a well-thought testing effort, the project will undoubtedly fail overall and will impact the entire operational performance of the solution. With a poorly tested solution, the support and maintenance cost will escalate exponentially, and the reliability of the solution will be poor. Therefore, project managers need to realize that the testing effort is a necessity, not merely as an ad hoc task that is the last hurdle before deployment.

The project manager should pay specific attention to developing a complete testing plan and schedule. At this stage, the project manager should have realized that this effort would have to be accommodated within the project budget, as many of the testing resources will be designing, testing, and validating the solution throughout the entire project life cycle—and this consumes work-hours and resources. The testing effort begins at the initial project phase (i.e., preparing test plans) and continues throughout until the closure phase.

Testing Criteria

It is essential to conduct tests under realistic conditions. Often times the testers on a project deliberately go out to destroy the solution during the testing phase in order to do a proper test. Some sensible ground rules for acceptance testing are necessary and need to be established before any testing commences. Typically, some of these rules should include the following:

• Using real data and real operators.
• Test the solution as the developers build it. This way, errors can be corrected immediately.
• Involve project members who understand design and user specifications.
• Determine what is included within the test and what is not.
• Involve users of the project who know how the system will be used.
• Test to see that interfacing the new solution to the current infrastructure has no unexpected consequences.
• Allow time for repetition of those unsatisfactory test results in the project schedule.

Types of Testing

There are many different types of testing that can take place on an IT project, and the project manager must verify exactly which tests will be required and when. Below is a list of the most common types of testing that usually encountered on a project:

A Lessons Learned Template

Lessons Learned – often talked about, a discussion that is usually planned…but often forgotten.  You’re at the end of the project and the plan is to pull both teams together to go over lessons learned in great detail and for the benefit of all – but it often doesn’t happen.  Team members move on to other projects or post-deployment issues are taking up everyone’s time.

Lessons Learned sessions can be very helpful – and if you’re luck enough to keep yours on the project schedule, then this template may help you.  It looks a little rough pasted into this post and one of the tables turned into a bullet list, but I think you’ll get the idea.

As always, if you want the Word doc template, let me know…and please feel free to share your version as well.

PROJECT LESSONS-LEARNED DOCUMENT

The purpose of this template is to help the project team share knowledge gained from experience so that the entire organization may benefit. A successful Lessons-Learned program will help project teams:

• Repeat desirable outcomes
• Avoid undesirable outcomes.

A. Your project team should begin to use this document at its first project meeting. Continually recording Lessons-Learned throughout the project is the best way to ensure that they are accurately recorded. Topics to consider include all of the following (feel free to change the list). The Lessons Learned Checklist is also available as a guide to discussion.

B. At the end of your project, use this document to summarize your experience.

During your discussions:

• Be positive
• Do not place blame!
• Focus on successes as well as failures
• Indicate which strategies contributed to success
• Indicate which improvement strategies would have the greatest impact

The signatures above indicate an understanding of the purpose and content of this document by those signing it. By signing this document, they agree to this as the formal Project Lessons-Learned Document.

Construction Software State of the Industry from Software Advice

My friends at Software Advice have sent over another interesting original article that they have put together pertaining to software in the construction industry. This one comes from Houston Neal and it kicks off a series of reports the group is doing on trends within the construction software industry. Please visit their site at www.softwareadvice.com for the original report.

Construction Software State of the Industry Report

This is the first in a series of “state of the industry” reports in which we will share our observations on construction software industry trends. While reporting the recessive state of the industry is not breaking news, there are some interesting trends that we can share. Not everything is gloomy, and significant technological shifts are underway.

Our observations are based on roughly 6,000 conversations with construction software buyers over the past year. In these calls, our team listened to buyers’ “pain points” – the business problems they were looking to solve with new software. From there, we recommended what we felt were the best solutions. We later surveyed each buyer to find out if they ended up buying software, what they bought and how it all went.

Estimating and takeoff solutions are in demand

We’ve seen a very healthy level of interest in construction estimating software across all divisions. Over and over we hear contractors saying something to the effect of, “Bidding has gotten very competitive, which means I’ve got to be as accurate as possible.” As a result, we’ve seen a lot of estimators replacing their spreadsheets and manual processes with database-driven estimating systems.

We’ve also seen plenty of interest in on-screen takeoff software. We’ve seen three primary reasons for this:

• Increasing the speed and accuracy of takeoff measurements (see previous paragraph);
• Avoiding the printing costs of paper plans; and,
• Responding to increasing electronic plan delivery and use of online plan rooms.

While demand for onscreen takeoff appears fairly strong and growing, we have seen a considerable amount of downward pricing pressure in that market.

Software as a Service is in the right place at the right time

Software as a Service (SaaS) is gaining momentum in many software markets. In fact, we would agree with other IT prognosticators that SaaS is a major structural shift in software deployment and is here to stay. We’ve seen this model succeed in the project management segment where there is a clear need for the collaborative benefits of web-based software. Moreover, the current recession is making the SaaS model more attractive to contractors because:

• Subscription pricing can easily be added to a project’s general conditions;
• Low up-front costs allow project managers to avoid an onerous approval process; and,
• Faster and less expensive implementation makes the new systems more digestible.

We have not seen much demand for SaaS accounting, estimating or service management, although we do get asked about it now and then. We also have not seen many vendors emerge to deliver that sort of solution. We would not be surprised to see SaaS accounting and/or estimating solutions emerge over the next few years.

LEED credit tracking creates new demand

Another trend driving the adoption of SaaS project management systems is the increasing demand for LEED credit tracking. LEED certification has grown in popularity; so too has the need to track the detailed documentation requirements related to earning LEED credits. At their core, projects seeking LEED certification need document control and efficient communication. This is the core of what project management systems deliver. Going one step further, we are seeing a number of project management vendors building in specific LEED credit tracking modules within their system. Houston Neal wrote a great post on how to Track LEED v3 Credits in Project Management Software back in July.

Stimulus funds are trickling down, slowly

Government and other civil construction has remained healthier than commercial and residential construction. However, we have not seen the American Recovery and Reinvestment Act of 2009 (ARRA) have a big impact on software spending. We believe that the temporary nature of stimulus spending is not enduring enough to drive capital investment in software systems. Our hope is that ARRA will help accelerate the economy to a point where traditional IT investment levels resume. However, Chris Thorman recently wrote a quick analysis of the ARRA that showed that stimulus spending has had a nominal effect on putting roughly 1.6 million unemployed construction workers back on the job.

There has been speculation that Stimulus-funded construction projects would drive sales of project management software. The thinking behind the forecast was that ARRA projects would require a higher level of accountability. Project management software – known for strong document tracking capabilities – would provide the audit trail needed for this transparency. However, we have not seen this translate into a meaningful increase in sales.

Fewer accounting & job costing replacements

We’ve seen fewer firms replacing their core accounting and job costing systems over the last year. In prior years, we had seen replacement activity when company growth pushed existing systems to their limits. In the absence of growth, more firms seem to be staying put with their existing systems. Firms that are buying new accounting systems tend to identify one or more of the following three pain points:

• Inability to achieve detailed job cost reporting from “generic” accounting systems;
• Lack of integration to project management or service management systems; and,
• The need to accomplish same amount of work with fewer employees.

Outlook for 2010

As the construction industry begins to rub its sleepy eyes, we agree with most experts who say that 2010 will be a transitional yet slow year for the industry as a whole. Company budgets likely won’t fully recover in 2010, limiting the purchase of construction software. However, so far we’ve noticed more activity this quarter than any other this year. Hopefully this level of interest will carry over to 2010.

This article originally published at: Construction Software State of the Industry Report.