The Cost of Planning for Web Site Enhancements

Introduction

How often have we heard the line, “Tell the vendor to support as much features as possible upfront so that there won’t be a need to revamp from ground up later” ?

Unless a vendor happened to have recently or frequently implemented an exact system, and has the details fresh in mind, it is not likely that they can trivially go through the list of possible future upgrades and say YES we’ll factor them in.

Usually, vendors will promise it just to secure the contract. In reality, they would not have put in enough planning effort to substantiate their claims.

Common underestimation of effort

Refer to the picture below.

Resource projection for implementing enhancements

Figure A illustrates the base condition of designing and implementing a Web site with 8 features (blue blocks) as one contiguous project.

Figure B illustrates the wrongly projected effort required for the same project. It is implemented with 4 features first, because the current budget is insufficient. The remaining 4 features may be added as future enhancements.

Figure C illustrates the correct projection. There are 3 differences from Figure B.

1. The immediate effort to design the architecture to cater for future enhancements is greater.
2. The effort needed for each of the future enhancements (green) is greater.
3. Lastly, only 2 of the 4 immediate features (blue) can fit into the budget / time.

The reasons for the 3 differences as follows:

Why more effort needed for architecture
Planning for future compatibility deals with uncertainty and risks. Uncertainty means the architect needs to think of all possible scenarios of what each feature may do. This requires much more effort compared to knowing exactly what each feature will do and planning precisely just for that.

Why more effort needed for future enhancements
By the time the enhancements are to be built, the momentum of the project could have died down. The original team may have changed – knowledge transfer is not perfect and takes time. The actual requirement may differ. Costs may have increased.

Why the immediate features cannot fit into the budget / time
It should be obvious by now that this is a consequence of the increased effort needed to architect a future-proof foundation.

Conclusion

It is natural that time and budget limits all the features that we would like in a Web site. It is common knowledge that failure to plan for the future will cost the stakeholders. I wish to highlight that (a) the act of planning itself should be associated with a non-trivial cost and (b) the future always carries risk – so buffer it in.