The Politics of Design

Implicit Requirements frustrate users, cause project overruns and create an expectation gap between IT and Business. Implicit Requirements are those “common sense in hindsight” items that often go undocumented. They squeak through at requirements reviews because, while everyone in the review nods their heads in agreement, they were agreeing to their individual interpretation of the requirements leaving large gaps for implicit requirements to grow.

Implicit requirements exist in many aspects of our lives. For example, if you’re installing a door on the front of your house you shouldn’t have to specify that you want it to lock, operate smoothly or open and close! EVERYONE understands those requirements. Right?

However, “common sense” requirements are not as clear when it comes to the nuances of business and technology. This is particularly true on Business Intelligence (BI) projects because BI teams are staffed with specialized skills which tend to result in more challenging hand-offs between the various roles (Business, BA, PM, Developer, Architect). This is compounded by long BI delivery cycles, which means the Business does not see the finished product until the final phases of the project.

The Business is reasonable in expecting all rows to sum correctly and “generally known” KPIs make sense (such as not showing $100 Billion in revenue when the company makes $50 Million) but calculations for yield curves and complex interest calculations should not be left as “implicit”.

You might wonder “if IT just understood the business better, it would remove the gaps”, right? Taking you back to the front door example: everyone understands the problem domain (how to use a door) and most can conceptually understand the solution domain (remove old door, install new one, make sure it is level, plumb, etc) but few (if any) understand the complex calculations that Finance and Risk folks use to steer your business AND understand all of your source systems where the data is stored, how to process this data through ETL, Data Warehouse and Semantic layers and finally present it to a user.

Two common approaches to remove gaps are:
#1 Strong Process Solution: Follow thorough / rigid processes to ensure the business gets exactly what they want and need.
#2 Super Team Solution: Build a team who deeply understand the business and the technology domain so well they can complete each other’s sentences.

Approach #1 is fraught with slow moving, high cost projects filled with red tape. Approach #2 may work for a while but will end up building silos in the organization and stove pipe solutions because each Super Team will focus on their domain and their set of solutions and not necessarily think cross-Super Team.

The art here is KNOWING WHEN to apply the right approach. There will be projects that require very detailed requirements (strong process) and there may be projects that require you to “fly the pirate flag” and build a temporary super team but, i’d bet the majority of projects just need a little extra common sense.

The same common sense required to understand when to flush out a requirement because of a potential gap. Everyone on the project team should be able to do this but Architects need to be particularly good at spotting gaps. Business Analysts are heads down in the requirements and the Development team may already be thinking in the solution space but the architect should be considering broader implications to the application, data or technical landscape and need ensure that expectation gaps are clarified.

To minimize expectation gaps:
1. Hire strong people who will take initiative and cover for each other in case a hand-off is not clean.
2. Consider agile-like processes so the business can see the final deliverable a little at a time.
And look at the members of the core team. Just like installing that front door, if they don't have at least conceptual understanding of how the business intends to use the new deliverable and don't have experience in installing it...you might want to find some different carpenters.

Do ERP projects face more Implicit Requirements challenges than Custom Development (Microsoft, Java) project? What are good examples of Implicit Requirements to share?

red door