They (signoffs) play a very significant role in the project lifecycle and add tremendous value and leads to an overall positive outcome to your project. But like everything else, there is a time and a place to use signoffs. Using a signoff should not cause and be looked at as an unnecessary burden.
I have seen that using signoffs during a software implementation that is using a waterfall methodology is most appropriate. There are distinct phases, each phase is broken out into more granular tasks and everyone is aware going into the project on what happens next.
On the flip side, the agile software development projects I have managed are much more difficult to implement signoffs on. The very purpose of “agile” breeds the possibility of things never staying the same, therefore, how can I tell my client to signoff on the requirement or a feature that has a high degree of changing in the next development cycle or the next test cycle.
My waterfall training as a project manager always told me that there are distinct gates that you cannot pass through and move into the next phase until you have signed off saying you agree to what was delivered and agree to what you are going to be receiving before you moved into the next phase. The signoff also meant that you, as the client, would think long and hard before coming back to me with a dispute.
Being new to the agile world, I made the mistake of going to the business owner with my deadline on finishing up with requirements at a set date. That is when I came to the realization you need to be a little creative based on the situation at hand. For the agile world, we came to the agreement that a signoff only meant that the users are agreeing to the documented requirements at that moment in time and that there are no BIG requirements missing that they are aware of. My other goal with this signoff was that I was getting the stakeholders to review the requirements with the fine print stating that this requirement has a possibility of changing at the end of the development cycle.
On the waterfall side of software implementation in contract to software development, the lines drawn are much more visible and easy to identify very early in the project lifecycle. Getting signoff from your client or sponsor is simple because there is a clear deliverable. Historically, what I have found to be difficult for me is to communicate the implications of going back on a signed-off document.
It is absolutely acceptable to change your mind and say, “I said YES last week, but there are now new requirements that make that sign off invalid”. In these situations, the project manager plays an important role in communicating the impact; but my cynicism in this process lies in the area where there is almost always a great deal of backlash.
In the end, almost all project risks, issues, or backlash is either reduced or eliminated with the appropriate amount of communication.
To learn more about “signoffs” or project management in general, please don’t hesitate to contact Amit by calling 301.360.0001 or by emailing sales@ktlsolutions.com.
AMIT TRASI | Project Manager
Amit is responsible for institutionalizing project management governance at KTL to streamline ERP implementations. With over 15 years of technology experience as a software developer, project manager, and program manager, Amit has managed end-to-end ERP implementations with Dynamics NAV and GP as well as POS implementation with e-Commerce front end. He holds extensive experience deploying POS and ERP applications at non-profits, theme parks, and museums across the United States. Amit joined KTL in October of 2013 and holds an MBA in Information Systems as well as holding a Project Management Professional certificate.
