Vision (A. Vision in the Togaf ADM) at an Enterprise level is something that ensures alignment to the Enterprise’s business strategy. At a lower level of detail – a defined programme/project – the vision and scope can be synonymous. However, scope is not only about the business vision for a project – usually involving some element of I.T. – but critically identifies key information that enable the various incumbents. It is sometimes contained in a Scope Document, a Change Request, an Project Initiation Document, etc. Irrespective of the vehicle of transmission, from a Solutions Architect’s perspective, a successful scope artifact contains the following:
- Sponsor
- It must identify the Sponsor. While this artifact is all about ensuring clarity of scope and vision, there are occasions where the Sponsor needs to be Responsible, Accountable, Consulted or Informed. They are after all holding the purse strings and any deviation that needs assessment as a result of greater degrees of delivery clarity needs their acceptance.
- In addition to the Sponsor, stakeholder management is crucial to the success of a project and therefore some may deem that an early stakeholder management matrix – or other such tool – should also be defined in collaboration with the Sponsor and the I.T. Architecture function. In a mature organisation, this should be relatively easy to form.
- Business Context
- This is simply the introduction and background of the business areas that are subject to the request for I.T. change to occur.
- It must contain reference to People, Process, Technology and Data – related to the drivers/need for change.
- It should contain ubiquitous language but that depends on the success of the Business Architecture and Information Architecture domains within the Enterprise.
- All other deliverables that are produced throughout the SDLC, should reference this Scope artifact.
- Problem statement
- There’s not a lot to say about the definition of a Problem Statement. There’s a problem! Describe the problem.
- It must be agnostic of solution visions/future state. This document is predominantly by the business sponsor/representatives with support from the Business Architecture and/or Analysis community.
- Business Aims, Goals, Objectives
- Simply put…What are the AGOs the business sponsor is aiming for?
- For those interested in how to define these I would suggest reading up a little on the difference between the three terms. AGOs IMHO are hierarchical and there’s probably some science to which are best for defining the scope within an IT change project. I personally haven’t paid much attention to the fact they’re written at a Goal level, Physical Behavioural Objective level, or otherwise. I just ensure we all understand them and they’re divorced from the future state technology solution. The relationships between them are of greater benefit to the Executives, so they still ought to be correct and provide traceability to Organisational strategic direction, not just the business area.
- Once again, it must be agnostic of solution and technology future state design. There are so many options available to deliver business value through People, Process and Technology that Technology should not really be the focal point… but if it is then it can’t be avoided. The options and decisions and recommendation formulation must be left in the hands of the Subject Matter Experts (SMEs)…usually Architecture. Architectural Decisions may be provided as an artefact in their own right and I will discuss this in detail in a following article.
- Note that I am not precluding the use and communication of Technology need .e.g. A web presence that builds brand/product awareness, a database of citizen information that can be shared securely, etc.
- Strategic alignment
- Business strategic aims are what make us all move in the same direction. When it comes to a project scoping, it’s no different. It’s really useful to understand how the business’ strategic aims are being delivered through this project and in what way.
- If the alignment has been formulated by someone from I.T. (.e.g. Enterprise Architect, Lead Architect, etc.) and are worded using the Enterprise Architecture function’s aims, then that’s fine as long as everyone has bought in to them.
- Functions required
- This is where there ought to be a careful marriage of technical solution and business need. It’s really a placeholder for some really high level functional requirements. Once again, however, it should be worded in a technology agnostic manner.
- Critical success factors (CSF)
- The benefits, while perhaps perceived at this point in time, and/or are highly subjective, give greater insight and focus in to the acceptance criteria that we can measure “success” by. This introduces the level of measurability that IT change project’s all too often forget about, or lose focus of.
- I am not, once again, referring to KPIs. KPIs quantify, CSFs qualify. For example:
- A KPI may be the increase in the number of orders processed. A success factor may be automated processing of orders that were previously part of some slower manual process.
- Assumptions (RAID)
- Assumptions speak for themselves. What I will hopefully cover in the future, however, is how Architecture needs to deal with assumptions. All too often, I find that assumptions – and sometimes risks and issues – are left unmanaged. They need to be ratified, actions plans created, etc.
- You might want to also capture Risks and Dependencies known at this stage.
- Constraints
- I’ve separated constraints from RAID information as there are, on occasions, constraints known that don’t fall in to any of those classifications. For example, budgetary constraints, or constraints based on the principles of strategy, enterprise programmes, etc.
Without the above, projects are doomed for some level of failure, or at least perceived failure. At the very least, a good architecture cannot be built on anything less.
Some might say that it is really useful to understand the business’ expectations, or limit, in terms of budget, so we can make an assessment of the best architectural decisions. This is highlighted as a constraint above. I’m not precious about where it lives but it must be clearly understood. Are we building on a shoe-string budget, do we have a critical path that dictates cost vs benefit?
The CSFs sometimes have a perception of what the overall saving in money and/or full-time employees would be. However, all too often it is relatively meaningless until we’ve had some technical oversight (Architecture) and apply a bit of thinking, get some estimated costs (people, process, technology), etc. It can then all be bundled up in an early iteration within that analysis & design/elaboration/feasibility/idea/Envisioning phase.
This leads me in to more about the Architecture process, before I delve back in to showing some of the key characteristics I believe are a minimum to what good Architecture looks like.
Useful Further Reading
Scope definition and management
- “Scope Management” by the Project Management Institute: https://www.pmi.org/learning/library/scope-management-9099
- “Project Scope Statement How-To Guide” by Wrike: https://www.wrike.com/blog/how-to-write-a-project-scope-document/
- “Project Management Lifecycle” by Wrike: https://www.wrike.com/project-management-guide/project-lifecycle/
- “Scope Management Plan: Everything You Need to Know” by ProjectManager.com: https://www.projectmanager.com/blog/scope-management-plan
AGOs
- “Aims, Goals and Objectives” by the University of Edinburgh: https://www.ed.ac.uk/academic-services/undergraduate/aims-goals-objectives
- “Goals vs. Objectives: What’s the Difference?” by the Balance Careers: https://www.thebalancecareers.com/goals-vs-objectives-difference-2276096
- “Writing Goals and Objectives” by the University of Tennessee, Knoxville: https://teaching.utk.edu/2017/01/11/writing-goals-and-objectives/
- “How to Write Objectives for a Successful Grant Proposal” by The Balance Small Business: https://www.thebalancesmb.com/writing-objectives-for-grant-proposal-2502092
- “What’s the Difference Between Goals and Objectives?” by MindTools: https://www.mindtools.com/pages/article/newHTE_90.htm