This is the final part of a three-part series by leading project management expert Brad Egeland. part 1 part 2
Step 4: Execute with Best Practices
What exactly are best practices? There really is no set list of best practices – it changes from organization to organization and from project manager to project manager. For PMs with a significant amount of experience, many of the things that are generally considered ‘best practices’ are things, hopefully, that we do without even thinking. For newer PMs, however, these concepts can not be taken lightly as they may not be intuitive yet and newer PMs may even be working in an organization that provides little to no support for the PM process. In some smaller organizations or companies where IT is a sidebar rather than a primary focus, the newly anointed PM may be standing alone trying to get their arms around a portfolio of ‘projects’ in various stages of disarray.
How do you jump in and take over managing in this type of situation? Let’s consider what some of the general ‘best practices’ are that any project manager should be ready to employ as basics to getting started on the road to good, solid, project management performance. Paying close attention to these 5 key areas will help the project manager stay on track toward a successful project conclusion. The degree of effort that is put into any of these areas depends on the size, timeframe and budget for the project, but they all must be performed.
Scope Management
Get a good handle early on as to the proposed scope of the project that you’ve been handed. Gather as much info concerning the scope from whoever closed the deal and handed you the project. Jot down any project requirements you don’t fully understand and be sure to discuss those in detail with your customer before or during the kickoff meeting. This proposed scope is critical because it is the basis for the project, the input for the project schedule and ultimately what your project will be judged against.
Reporting
A good rule for the PM, at a minimum, is to provide your team and your customer with the following, in terms of project reporting on a regular basis:
- Weekly project status report
- Weekly budget status/forecast update (if applicable – discuss with your customer early on)
- Weekly revised project schedule
The project status report will be the document that drives the weekly status call with the customer and the weekly revised project schedule will be what shows the team and the customer whether or not the project is on track and will let each team member what their responsibilities are for the week and for the rest of the project.
Budget Management
It’s imperative that the PM manages the budget and the forecast (both financial and resource) very closely. Whether that gets shared with the customer regularly may be a matter of corporate policy or may be based on your customer’s preferences. But at the very least, the project manager must be on top of this at all times.
Losing control of the budget and the forecast – which can be relatively easy to do – can cause major problems down the road as the project nears completion. Finding out in the late stages that you’ve run out of money is hard news and sharing it with your customer as a ‘surprise’ will not only result in great customer dissatisfaction, it may either get you pulled from the project or it may get the project canceled on the spot. Both are bad for your career.
Timeline Management
The project schedule is what lays out the entire timeline for the project identifying key deliverables and milestones. As mentioned in Reporting above, the project schedule is a critical piece of information for each project team member and must be revised and distributed weekly to everyone.
I’ve not managed a project yet where the original project schedule remained unchanged throughout and I just managed from it. Because of change orders, issues, customer preferences, or revolving project resources, there are monthly, weekly and sometimes daily changes to the project schedule. Those must be accurately noted and distributed to the team and the customer on at least a weekly basis.
Customer Communication
As the project manager, how and what you communicate to the customer will go a long way in determining customer satisfaction on the projects you manage. Keep them engaged in all critical project communication. Don’t keep the bad news from them…but don’t tell them the sky is falling all the time either. If you have bad news to share, be well prepared to deliver it. In fact, it’s best if you already have a planned course of corrective action. But if not, share it with the customer and ask them to share in the corrective action. It’s their project, too…and they want you to succeed.
Summary
Best practices can mean different things to different people, different project managers, different customers and different organizations. Essentially, they are what helps a project manager effectively and efficiently manage the engagement while equipping him to do the best he can to bring home a successful project with a satisfied customer. Whatever you or your organization choose as key best practices, make sure that they can be easily implemented and followed so that your team of project managers can utilize them on every project going forward.
Step 5: Make Testing a High Priority
Any technical 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.
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.
Summary
Testing is critical. User acceptance testing (UAT) is an absolute necessity. And even though most customers are not well prepared for UAT and the delivery team knows the project solution inside and out, refrain from the urge to skim over this part or to do the testing for the client. You can help them prepare for it, help them put together test cases, etc., but don’t do it for them. You need their approval that the system has been thoroughly tested by them and that they do, indeed, accept it.
Step 6: Run a Flawless Deployment
The title of this chapter is actually a little tongue in cheek. I’m not sure there has ever been a flawless deployment in the history of project management. At least I’ve never run one, experienced one or seen one from a distance. You’d like to think that project closure is a joyous time to leisurely run through the final steps of the project and hand off a workable solution to a waiting, happy project client. That isn’t how it usually goes…
As the project comes to closure, you’ll usually find yourself knee-deep in administrative and signoff tasks not to mention work related to those tedious remaining issues that make the customer very nervous at deployment time. Your duties as project manager certainly don’t cease … they actually may increase. It isn’t the case where you let your project team hand the solution off to the customer and turn everything over to technical support (if they are even going to be needed on such an efficiently designed and thoroughly tested solution). In reality, you will usually find that you are dealing with lots of things going on at once and you’re also dealing with two separate sets of team members – yours and the customer’s – who are being pulled by their respective organizations to free themselves up for new and exciting projects. They’re working in shutdown mode and it’s difficult to get the productive hours out of them for YOUR project right now. It can take all of your resource management skills just to keep team members engaged.
Customer Issues
- Complete all deliverables
- Install and test deliverables
- Prepare operating manual
- Prepare maintenance manual
- Train customer’s personnel
- Agree on level of follow-up support
- Conduct formal acceptance review with customer
- Verify customer satisfaction
Organizational Issues
- Summarize learnings – communicate to the organization
- Prepare final technical reports
- Evaluate project performance
- Conduct final review with management
- Prepare project historical files and place in archive
Personnel Issues
- Recognize/reward team performance
- Write performance evaluations for project team
- Assist in reassignment of project personnel
Administrative/Other Issues
- Dispose of leftover project material
- Close down temporary site operations
- Submit final invoices
- Forward all final payments
- Close out project charge codes and work orders
Summary
This is merely a generic list. A true project completion checklist would need to be tailored to your specific project and each industry is going to have different things that need to be included in the checklist. And several items are really just follow-up to things that should have been agreed to long ago with the customer, such as “agree on level of follow-up support.” That was likely set in stone during kickoff or project planning sessions. Finally, always keep the project schedule and detailed tasks managed through deployment. If your project closure activities are massive – as they can sometimes be on government contracts, they may even warrant having their own, separate project schedule.
