This section is about boundaries
This blog is the second one in a series of four that represent my background and how I reason. As a designer, I might appeal playfully, unorthodox, and intuitive, but a methodology guides me behind all that. Not as a straitjacket but as a touchstone.
If you want to think "outside the box," you'll first have to recognize the boundaries that shape that box.
During the course of a project, the emphasis is successively on these 4 phases
Why?
What is the problem you're trying to solve?
What’s the business case? Or do we need to define one? That is the essential question in this matter, and when you ask the question precisely: “what’s the business case? ” To a subject matter expert or the problem owner, you’ll end up with puzzled faces.
There are two trick questions.
- In case of a new request for an (IT) solution, ask: “what if we do nothing?”.
- In the case of an application rationalization ( a process to simplify, standardize, or converge an IT legacy), ask, “What if we shut down this application?”.
The answer will open the dialogue to the business case. But don’t hesitate to be a little nagging and pursue your exploration by asking questions like “why is that a problem?”. A friendly face and a gentle atmosphere are important in this place because you might come over as a treat to people that make a living by operating a process that is so dumb that a computer can do it.
Financial boundaries
What can you spend? Is there any budget or sponsored driver to invest in the solution in mind?
Can you propose a business justification?
Do you have so much money you can spend on frivolities, or do you need a business justification to invest? Return on investment provides a clear view of the justification to invest in the new “tool.”
In the public domain, you can sometimes pull the card of service grade.
Strategy
Is there any strategy in the organization that you need to comply with?
Legal boundaries
The designer needs to know what the legal boundaries are. Legal expertise is essential in the demand assessment phase. But there is one thing with these legal experts that you need to take in mind. Please don’t hesitate to ask legal permission for a solution. That’s not like a lawyer giving permission. These people know a lot about boundaries, but you must present your solution with an attitude like: “Given the boundaries that are provided, this is the proposed solution!” Then, use silence and allow people to let it ground. The designer must accept authority in this matter.
lawyer noun law·yer | \ ˈlȯ-yər \ plural: conflict
Legal Definition of lawyer : one whose profession is to advise clients as to legal rights and obligations and to represent clients in legal proceedings
Are there any business standards that you nee to comply too?
Think of industrial standards in aerospace, automotive, finance, food or pharmaceuticals, healthcare, etc. Think of what the organization has committed itself to. These standards might require a specific process approach; traceability is key.
What are the (company) internal business rules?
They sometimes come top-down from a business strategy, and more often, they exist in the collective memory of a company. In some cases, people make an effort to define a company policy. Sometimes a designer identifies shortcomings in the set of rules and, in that case; please hesitate the propose tangible, realistic business rules and have them validated.
Architectural principles?
What is the set of architectural principles that an organization is using? You cannot ignore a policy like SAP/ Microsoft unless. What about cloud policy?
Train the people that you need for your discovery
Before going into demand assessments, I always start with awareness training. In 3 workshops of 4 hours each, we will get to work with the tooling like M365. True hands on playing and discovering via tinkering in a dedicated playground environment.
Assemble a functional governance team
Functional governance (design and enforcement) requires a multi-discipline team. It’s not that you need the full audience every time, but you will need to talk to people with a background in legal matters, security, personal data & HR-related matters. You will need to talk to “the business” because that is the audience we are supporting, and that is where you’ll find the subject matter experts. Of course, IT has a saying too.
Those people that you going to talk to are all process specialists.
It's the role of the functional designer to bundle that strength.
Think of the ten commandments. Essentially, it’s a rudimentary process description of how to run a society. Take it out of religious context, then you start to discuss legal matters. When you read law text, you’ll find rules about social behavior, how to act or what not to do, and in the case of criminal law, it also describes the penalty when you violate those rules. OK, the writing style is often very complex, but when you take the effort, there is enough process description to accept that lawyer as your peer.
The same goes for security experts or subject matter experts. During demand assessments, these people bring their specialism into the discussion. The solution designer must be the generalist that must find the open spot in the jungle of restrictions.
The quest for design space.
It might look like a nice open space to build you home.
You’ll find schools, museums, hospitals, shops, and a lively social atmosphere in the nearby area. The environment is hot!
There will be constraints, not only money because a square meter will cost you about 1 Zillion dollars. Plumbing can be a problem too.
Try to be realistic when you find an open space in a jungle of rules and constraints.
The theory of constraints
The theory of constraints (TOC) is a management paradigm that views any manageable system as being limited in achieving more of its goals by a very small number of constraints. There is always at least one constraint, and TOC uses a focusing process to identify the constraint and restructure the rest of the organization around it. TOC adopts the common idiom "a chain is no stronger than its weakest link". That means that organizations and processes are vulnerable because the weakest person or part can always damage or break them, or at least adversely affect the outcome.
