[TABLE]Oh, that delicious moment when after months or even years of hard labor, you finally get your project signoff. It's the ultimate statement from the customer that your job is done, that he is satisfied with the result. It was a fun time, but you are glad the tasks are complete and are ready to move on to the next gig.
However, getting project signoff can be a pain. If you think that you can just run your project plan and send a mail to your sponsor that you're done, you are in for quite a surprise: It isn't over before he says so. You probably run around the office with your approval forms to get some signatures, but prepare for some brush-offs. For the project manager, this event marks his transition from one job to the next one. But for the client, the end users and a lot of other stakeholders, this is a major thing -- the cutting of the cord. After placing a signature, they are left to their own devices. Perhaps not literally, but this will be how they see it.
There can be several reasons why people are reluctant to give you the official signoff:
You have to plan for a smooth signoff. When you start a project, more than likely signoff is not on your mind, but it should be. It is the answer to every project's dilemma: when are we done? This is a money, time, quality and functionality question. Of course, at the beginning of your project you will have some statements about that. Heck, you might even choose to do a very detailed specification of what you have to deliver upfront (which has some other problems in itself, but I will not go into in this article). But let's be fair, during the project all that stuff is likely to change: timeframes may shift, the available budget might alter, and for sure the system requirements will go from left to right and back again.
So, the answer to "when are we done" is a moving target. But that's fine, you can handle that.
Communication with
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
end users, sponsor key
The solution to reason number one, where the customer doesn't think you delivered everything that was agreed upon, lies in continuous feedback to the stakeholders. Your beacon of light should be the business goals you have to fulfil; they provide you with more room to operate than screen mock-ups. And in the end, this will be the measuring stick that higher management will judge the project by.
By doing multiple short iterations in software development, you can show users what they are going to get. Record their opinions, and record what is still missing or wrong. By engaging in a discussion about what should be done next, what is missing the most, and what is most important, you are managing the expectations of the end users in such a way that after a couple of iterations they feel so involved and excited that they will almost automatically approve the system. Heck, they practically built it.
The same communication applies to the sponsor. By continuously keeping him in the loop about the schedule and budget, you are managing his expectations. And while the project progresses, the "when are we finished" question becomes more precise. For example, it may be that in order to compete with another company, a certain service has to be launched before an ultimate deadline (otherwise the company looses market share). However, while doing the project, it might turn out that it's better to release the service later than the competition and provide a better service. Or perhaps it's better to quickly build a crappy cheap service that will be thrown away after a short period of operation. The business goal was to keep up with the competition on a certain new service, but as you can see that can be dealt with several ways.
Communicating with the sponsor on the project's progress will help you keep his expectations in line with reality. And by using iterative development you can steer the project at regular intervals in the direction needed. There will also come a point of no return where you can decide with the customer that the last two iterations have arrived; you will do this and that, and that's it. And having run several iterations already, you will have a fair idea of what you can do in that last phase.
You might get the feeling from this that a project doesn't have an end to it, at least not before the end is in sight. In some ways, that's true. The real end of a project may be defined by different things: the schedule, the budget and the functionality of the system. The element with the highest priority defines the real end. With this real end just around the corner, it becomes easier to point at it and say, "You see that there? That will be the end!"
Note: Every time you agree on something with the stakeholders (users and sponsors) make sure you confirm it in a short email or something to avoid endless discussions.
Users afraid to run the system alone
To address the issue of end users afraid to run the system alone, people need to get used to that fact that you won't be around forever. Create plans with those involved to phase yourself out. Spend less and less time on site. If they still block this, force it with an unexpected absence. Deception isn't the best solution, but if you say you have an illness and can't get to the site, the users will have to learn to function on their own and their confidence will grow.
Work outside the scope of the original project
A customer may be reluctant to sign off on a project because he may want to add to the project. For contracted project managers who don't mind staying on, that isn't an issue. But if have other projects and jobs you need to attend to, use the above solutions to close the project as soon as possible.
Obviously it's best to get project signoff without having to force the customer to do so. You want the approval because the stakeholders are happy with the end result. And the best way to achieve that is through constant communication with them.
------------------------
About the author: Bas de Baar works as a project manager within the publishing industry and is the author of Surprise! Now You're a Software Project Manager.
