Wrap It Up: Finalizing the Project

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

You are a DBA, systems engineer, Web builder, Java coder .NET expert or any one of the dozens of different flavors that IT mavens come in. By default, that means you live and die by projects. They’re part of your work’s DNA, and there’s every good chance that you’ve just finished a project, just started one or are deep in the guts of one as you’re reading this article.

 

Good. That’s just where you should be: busy and employed. But all too often we forget to close out projects carefully. Once the work is done, the code written and the system built, once the testing and tweaking is over and we’ve hit something that vaguely resembles the finish line, new work starts calling our name. And we jump on it, inured as we are to the hectic pace of life in the IT world.

 

That’s bad. You need a formal way to close out your projects, and you need it for two simple reasons: First, you’ll learn more about your work, which means you’ll do better work over time. And second, you’ll get paid more in the long run. When they’re done well, project close-outs can boost your revenue, making sure you get paid for those last nagging tasks that loiter around the ends of projects like kids after school.

 

But first, you need to look back at the project you did and see how it went.

 

Cut Up the Cadaver
Project managers have a term for assessing a finished project: the post-mortem.

 

If you watch CSI or any one of the dozens of crime scene shows now on TV (and all the rage), it’s a term you’ll know well. And the truth is, assessing a finished a project is a lot like an autopsy. You and the project team, including the worker bees and the decision-makers, should meet at the end of the project to examine it like a scientist, with the detachment that lets you see the good and the bad in equal measure.

 

What went wrong? What worked out? Was it luck, hard work, preparation or a little of each? Did you face any problems you never dreamed of at the start of the project? Did you learn something—about the code you wrote, the systems you built or, more likely about how you work, how your team works or how you failed to work together for reasons that range from time zones to communication gaps to politics? Would you do things the same way again? Is there something to change?

 

These are just some of the questions to answer. It’s also paramount to write your answers down. The mere act of writing makes you think clearly—it makes you work to explain something with precision. So at the end of each project, write up a set of lessons learned. It will save you from repeating mistakes, and that can be as useful—and valued—as your client’s check.

 

Speaking of Checks …
Once you’ve finished a project you want to get paid—if you’re a contractor, of course. (Full-time employees and other cubicle dwellers rarely have to worry about a paycheck—it comes in the mail every two weeks, nice and steady.) But consultants live a different life: They live at the mercy of clients and their pocketbooks.

 

The problem, of course, is not merely getting that check. It’s getting paid for work you do (or work you’re obliged to do) even after the final payment is made. With the exception of digging a grave or toasting a bagel, projects are rarely truly complete. Even after you’ve finished your work, there will always by nagging tasks—a tweak here and there, a minor addition per the client’s request or a call three weeks after you’ve finished with a request for “one quick thing.”

 

The truth is, that’s fine. It’s par for the course in IT projects. What matters is that you have a way to deal with it, to do the work after a project is over yet still get paid for it. So when you close out your project, be sure that you and your client settle on terms for maintenance. If there are change requests, how often will they come? What type of turnaround can you promise? Will you charge a flat fee per request, or use a T&M (time and materials) contract? These are issues you need to settle as a formal step in your project close-out routine.

 

Archive!
Chances are, you wrote a busload of documents for your most recent project. Perhaps you had a project plan (you certainly should). No doubt there were change requests, key e-mails or memos, timelines, a Gantt chart or two, and all kinds of other data, from reports to code libraries, which might come in handy one day.

 

If nothing else, they’ll serve as a record of what you did, and for that reason alone, you should archive your project’s data once it’s complete. Gather the key documents together and sort them in a binder. If they’re electronic, publish them to an intranet or burn them to CD. (Use a standard naming convention to make sure you can find things quickly when they’re six months—or six years—old.) And remember that what you archive now can be used later: Your current documents become templates for new ones the next time around, and that saves you time, money and talent in the future. After all, not even the cavemen found it useful to re-invent the wheel.

 

Measure Those Metrics
At the start of your project, you wrote up a set of metrics to measure its success. Or to be more precise, at the start of your project, you should have written a set of metrics to measure its success. (Without them, you’re using opinion, not precision, to gauge your progress.) Now, at the end of your project, it’s time to do so.

 

Why? Because there’s no better way to justify your final invoice (apart, perhaps, from your contract) than to show your client the benefits of your work in hard and fast terms. If, for instance, you built a ticket system for an intranet, and it’s already begun to reduce calls to the help desk, show your client how many calls have been saved. Tally up the time and money that saved as well. And don’t forget the value of pretty pictures: Charts, graphs and other graphics can go a long way to making an impression.

 

Get A Referral
Funny thing about new clients: They want to know what the old ones thought about you. And even if you’re working in a company as a full-time employee, you’ll still need to build a track record of your work with different departments.

 

Rather than sing your own praises, let your old clients, internal and external, do it for you. At the end of each project, ask your client to give you a recommendation. Make sure it’s on his letterhead and over his signature. (If you’re an employee in an enterprise, this step is clearly not as vital to your work prospects. But it’s wise to have a department head or someone else—someone highly placed—write a nice, brief e-mail about the work you’ve done if the project was large.) Just be sure to do it quickly and not two, four or six months after a project is closed. You want users to write something good when the experience is still fresh in their heads.

 

And last, in your search for feedback, don’t be ashamed to seek critique. It’s true that it takes a strong ego to solicit that kind of response, and an even stronger one to take it without anger. But in the end, good honest feedback is worth its weight in gold. It helps you refine your work and your skills, and the more you know—and the better you perform—the more you’re likely to make in the long term. That’s a good enough reason to make open feedback a formal part of your project close-outs, and reason enough to make project close-outs a formal part of your project plans.

 

David Garrett is a Web designer and former IT director, as well as the author of “Herding Chickens: Innovative Techniques in Project Management.” He can be reached at dgarrett@certmag.com.

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
cmadmin

ABOUT THE AUTHOR

Posted in Archive|

Comment:

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>