Episode 27

People and organizations have tremendous pain thresholds. Old processes, obsolete equipment, and antiquated software are prevalent in organizations, but other constraints prevent these problems from becoming a priority to be addressed. Hacks and workarounds are the band-aids that get workloads pushed through the system. For instance, one organization had a procedure with instructions to kill the power to their computer and try again when a specific error code popped up in their case management tool. Eventually, the pain accumulated past the breaking point and the root cause of the problem needed to be addressed. Where to start and how to start? To break it down, this blog will look at the problem through both a macro and a micro lens.

Knowing where to start is best determined through knowing where you are right now. For instance, if you were standing on the North Pole and went one kilometer south, one kilometer west, and one kilometer north, where would you be? If you are to apply the same directions anywhere else on the planet, your outcome would be different. Knowing where you are matters!

Let’s start at the macro picture. Consider people, processes, and technology. Modern businesses are dynamic, multi-dimensional ecosystems. They carry their own momentum, and often the structure of their technology resembles the communication structures of the organization. Engineering and marketing firms are likely going to have different approaches to common problems like human resources, accounting, and information management. The people and resulting culture will influence the structure of the solutions that get deployed. Is your organization siloed? Does each department have their own technology tools? Does work get tossed over the fence? Are your IT services centrally managed? Conversely, is your organization structure flat? Are there multiple software solutions for the same problem? Are there challenges getting data from one solution into another? Understanding these initial conditions is important as they define the organization’s capabilities and preferences.

blueprints

Now let’s look at the micro picture. Start by taking an inventory of the applications used within your organization and their workflows. It is important to understand the dependencies, choke points, and alternative pathways available. The documentation process can take time especially if processes are fragmented and heavily dependent on individuals filling the gaps. For instance, are there individuals in your organization that do amazing work but it is unclear what or how they do it? Greater clarity at this stage will ensure that future task prioritization is more effective.

Now it is time to investigate the future, starting with the macro. Future states can be commonly viewed as strategic plans that include both business and technology goals. Future states can be documented as strategic and IT plans, corporate vision documents, or road maps. Business goals could include growing revenue, entering a new market, or reducing inventory in process. Technology goals could include reducing downtime, increasing responsiveness, or enhancing security functionality. Future states are tricky as the external environment can change so rapidly that strategic plans can be rendered obsolete in a matter of months. The COVID-19 pandemic is a clear example of how an environment change can upend a long-term plan. However, concluding that strategic planning is pointless, sets organizations down a path where accomplishing long term goals are lost in favor of reacting to the current situation. “Be proactive over reactive” is commonly stated when strategic goals have been ignored for too long. How can we build agility into the strategic planning process? First it is important to note that future states are important tools to provide focus; however, to provide agility, the path to the goal cannot be defined linearly.

path

To provide a pathway toward a desired future state we need to document requirements. Let’s look at the micro view now. Good requirements contain user stories, acceptance tests, and wireframes. User stories typically read “As a SOME ROLE, I want to DO SOMETHING, so that I can get SOME BENEFIT”. User stories can be best thought of as translation tools, bridging the gap between business users and the technical staff responsible for developing the solution. Acceptance tests include the scenarios outlined in the user stories, “GIVEN condition 1, 2… WHEN I do STEP 1, 2… THEN, desired result 1, 2…”. These are important for testing and confirming the solution behaves as expected, and should ideally be tested automatically through tests written during development. Lastly, wireframes are simple drawings that provide mock-ups documenting the user experience.

With these tools, a body of work can be created and placed into a backlog, visible to all. The backlog is then prioritized to ensure that the current focus remains in alignment with the goals defined by the future state. If the environment changes, priorities and requirements can be shifted as required ensuring that the work remains on a path toward meeting the organization’s goals.