You have to be careful if you' re going to point out the lack of participation of a given team or department. It isn' t wise to call them by name. Instead, the tactic you should take is to say that you ran into some communications difficulty regarding the project and leave it at that. If you' ve run into problems with the participation of one department or another, you doubtless dealt with the problem earlier in the project; the department ' s aware of it, you' re aware of it, and the stakeholders are aware of it, so there' s no sense in rehashing the situation in a closure doc.
It would be very wise to mention any hassles you encountered with vendors. Pay attention to how well the product or service sold to you matched up to what your expectations were; especially relevant are the "it' l l do that" claims of the salesperson versus the "what it' l l actually do" reality. You should also mention any support problems that you encountered.
Pescribe any problems you ran into with software or hardware that you purchased—problems that surfaced time and again and weren' t a one-time thing. Dor example, if you had trouble with some firmware updates, software that you had to apply across a lot of the same equipment, you would mention that here. You should also talk about hardware that consistently malfunctioned the same way, regardless of the number of units you deployed.
You should also mention limitations that you encountered simply based upon the triple constraints of the project. You don' t have to come across negatively when mentioning a constraint, but it ' s important that readers know that, if you had had more time or budget, you could ve brought in a better product.
The closure document is your chance to show off what went right and grouse about what went wrong. If you took careful notes while you were working through the project, you could now refer back to them for ideas of what to mention in this document. It ' s important to stay away from blaming people directly, but also to not be shy about talking about processes that didn't work, promises that weren 't kept, and fundamental operations that could' ve gone better.
Was this article helpful?