On paper, developing a web application is straightforward: figure what to build, build it, get signoff from the client, and launch.
Life is not so simple. Figuring out what to build can be complex because of competing requests from stakeholders, not to mention changing requirements through the development process. We recently launched a project where these complexities were apparent.
As consultants, we are outside the organization, and can fail to appreciate the multiple internal forces bearing down on our technology project. We can inform the client that increasing scope may result in delayed launch, but as consultants, our job is to then do our best to deliver what the client really needs. With our recent launch, we had several significant new requests AFTER user acceptance testing had started. The launch date was eventually moved back ten days.
I’ve worked on both sides of the client/supplier relationship, and this project gave me an appreciation of how different the perspective on the project can be from each side. From the client’s point of view, the project can be a component in a complicated political game – the requirements are levers to balance various stakeholder forces, and the delivery date is a message to organization from the project sponsor.
The supplier is focused on delivering a high quality project on time and on budget. Of course, we both start out from the basis of delivering a valuable business solution, but in the thick of the development process it became apparent how much simpler our supplier’s eye view was. Consequently, we dropped the idealized processes to help the client address their non-technical issues.
Among the lessons learned, I will emphasize the importance of cutting off new requirements before acceptance testing, but I am also now more willing to relax ideal processes when there are larger forces at play.
