Picture this, it's 1 pm and you've just had an enjoyable lunch break and you're ready for your next meeting. It could be called "Architecture JourFix", "Demand Review", "Technical Governance Board Review" or something similar. The important thing is that someone will be presenting some form of a business request to you in order to try and get your approval... or are they?
There seems to be a trend in many organisations where review boards are less about "supporting and approving requests" and more about "being informed of what we are going to do". Some teams see review boards as just another hurdle to go through that slows down their time-to-value. For this reason, the quality of the business request, documentation and clarity is often low. As a Platform Architect, I've had experiences ranging from good to laughable to deeply troubling. This article aims to cover the key aspects that should be addressed prior to requesting a review of a business need. At the very least, the team should be prepared to answer them. I've split these up in terms of "Essential" and "Desired".
Essential Aspects to Cover for a Business Request or Demand
I get that time is precious and we don't want to spend it writing documents. Especially when we know that the business need must be approved anyway.... right?! The goal of providing good answers to the essential questions is not only to confirm that the need is valid but also strengthen the why/what/how/who aspects to ensure success. A short-term investment here will pay-off down the line everyone that interacts with your request.
Business Context
- What is the current pain point? Why is there a need to improve or close a gap? What would happen if this request was rejected (provide insights on the "cost of delay")? Avoid talking about technology if possible. Eg, instead of "the dashboard is too slow", try "it takes fulfillers a long time to find what to work on next".
- What elements of technology, process and people need to be addressed? What has already been actioned and considered? What didn't work? What options do we have or were reviewed?
- Is it clear what success looks like? Is it measurable? How? Are audits required to ensure that behaviour has changed and adoption is high?
Cost & Impact
- What is the estimated number of users that will use this?
- How many users/records/transactions will trigger a ServiceNow subscription charge? Eg, how many fulfillers, custom tables, are there store app fees or IntegrationHub requests etc.
- How will this impact existing processes and other teams on the platform?
- Will this expand on an already custom component or introduce new complexity? How do we ensure that the impact of this request does not significantly add to the total cost of ownership for the platform?
Readiness
- How mature is the planned solution/business process? Is it a paper form that should show up on a webpage or is digital transformation properly understood by the requesting entity? Is a business process consultant involved or is it basically guess work?
- What types of users/personas and systems are required? How many exist in a form that can be used as is?
- How does this support "INBOX ZERO" and reduce reliance on email as a work or task based medium? Consider also other (legacy) ways of working such as with spreadsheets that could be replaced.
Strategic Fit
- How does this support and align to the strategies* for both the Platform and the Enterprise?
- How does this help us reach out organisational goals*?
- Which of the defined (architectural/business/technical) principles* and "golden rules" does this abide to? Which does it not?
* These need to be defined, easy to understand and easily accessible.
Additional "Desired" Aspects to Cover
In the case that the request "smells fishy" or there are concerns about the value, then these additional questions can help find the gaps and mature the assessment. Note that not all questions will apply to your context. Be creative and work out the right fit for the request.
Technical Approach
- What is the data lifecylce? How is data created, retired, deleted, audited, long-term archived etc.?
- How many tables are required? How many are custom?
- What core/master data will be used? Is it fit for purpose or needs enhancing?
- What integrations are involved? What is the expected cost to build and support them?
- How will this impact performance? What steps and tests need to be in place to ensure performance is not negatively impacted?
Security
- Who has access to this solution? Who should not have access?
- How will GDPR, data privacy and data security be supported?
- How will all of the above be audited?
Maturity
- Is the process based on a known and proven standard? What model process is being used?
- How are bulk requests managed?
- What approvals are in place? How are standard and bulk requests approved?
- What operational reporting elements are required to help identify gaps?
Long Term Support
- How will the solution be maintained and supported? What are the additional support groups required? Can they troubleshoot all issues?
- What is the roadmap? Where does the budget come from?
- What use cases need to be considered today and in the future?
Key Take-a-ways
The list of questions above can be used as a guide. It's highly unlikely that every question has a good answer. Make sure the quality gate or "rejection rules" are clear and that the open points are addressed at the right point in time. Eg, a tentative approval could be granted to continue investigation and engage other teams BUT the proposed development (platform changes) may need an additional deep-dive review to confirm previous assumptions.
Ensure that the process is a fun one and not a "slap on the wrist". Requesters need to feel supported and not punished. Always remind them of the goal to "find the best possible outcome" and they will be more willing to let you interrogate their request. Offer additional support sessions to help mature their request if their team is under-staffed or under-experienced. It may sound tacky, but "team work makes the dream work".
If you have other experiences or questions you think should be added then please reply below and I'll do my best to incorporate the feedback. Special thanks to Karsten Krommes who inspired me to write this post. The rant we shared was a good one and hopefully the output can help many others.
Further Reading
If you like what you read here, you may also be interested in these items:
- Ask Why by Chuck Tomasi
- How to gather and evaluate requirements by Anker Nielsen
