Barebones Agile DevOps (BAD) – A Simplified Hybrid Agile DevOps Approach for Delivering IT Cloud Solutions

By John Conley III

CEO, Samsona Digital

A division of Samsona Corporation

“Transforming your world one task at a time”

Tips for implementing a hybrid approach to solution delivery

You can have the best DevOps engineering pipeline in the world, but if you don’t control the flow of work before requirements reach the sprint backlog, chaos can wreak havoc on the dev team’s sprint velocity.

Having been a consultant at several companies during the digital cloud revolution (and before this era), I can safely say that most companies do not implement a pure agile approach. That’s fine. Life happens. Not all companies implement a pure Agile approach to solution delivery. Even those who use SAFe still mix in some familiar, waterfall or even unconventional methods. No matter how they slice it, almost all companies who pursue an Agile DevOps approach to IT delivery mix in unorthodox, home grown, semi-waterfall methods. If your company is one of these, then this content is for you.

Your company most likely sent teams to one of the many agile devops trainings available online and in person. Everyone is pumped up, ready to do some sprint planning. But the corporate technology culture is not sharing that enthusiasm. The “corporate culture tech debt” still wants the old ways of deploying technology.

Pure Agile and DevOps practitioners such as myself have to acknowledge that, despite the fact the Agile Manifesto was written almost 20 years ago, most organizations still fall back, by instinct, to waterfall approaches. Why? It’s mostly due to pressure from market forces, executive deadlines, and budget constraints. Human nature drives teams to quickly capture requirements and turn out code with little time for thought. Approaches such as Scaled Agile and DevOps have tried to balance this knee jerk reaction with some lightweight guiding principles, but most organizations still mix in pressure-driven waterfall regardless. Mixing waterfall with agile devops is what we notoriously call “WAgile.” We have to live with this grassroots behavior whether we want to or not.

Rule of Thumb: The more that IT shops veer away from an ideal Agile approach, the more chaotic their IT workflow becomes. Team members generally want to work their butts off to deliver quality solutions on time and within budget if organizations manage the chaos better.

Tip: When you hire new tech workers, be sure to document and train them on the aspects of your technology culture that are not part of industry standard methodologies or CI CD platforms. Just because a cloud developer knows Azure DevOps (the technology), for instance, doesn’t mean they understand all of the crazy complicated DevOps scripts you created (the technology culture). This also includes training senior technology leaders on the kinds of presentation templates that C-level executives want to see for status reports. These executive reports can vary widely per organization – I’ve literally had to have executive admins help me understand what style works best for certain C-suite execs. Separate the technology culture from the technology itself when onboarding team members. These are two different animals. Failure to adequately plan the training of technical team members such as architects and developers on unique homegrown practices is an antipattern I’ve observed in some organizations, including some mature agile organizations.

Figure 1. The Backlog Pipeline (High Level)

The Team Backlog

At a minimum, each team role needs its own backlog. Thus, not only should there be a developer sprint backlog and a product backlog, but there should also be an enterprise solution arch backlog, a security team backlog, a cloud platform engineer backlog, and QA backlog. If you use pure SAFe to manage the flow of work in and out of these backlogs, great. If not, at least when you manage your “wagile” pipeline—wagile being a waterfall-agile hybrid, just have these backlogs in place, at a minimum, so that the work can be organized and prioritized at the beginning of each sprint.

Neglecting any of these backlogs will increase the chaos of the solution delivery cycle, which will impact sprint velocity, and may lead to team member burnout and turnover. For instance, upper management will throw random work on the member and expect deliveries within 24 hours, despite the fact that the team already has backed up work that was due yesterday. This is where “office politics” usually increases because of the resulting personality clashes, escalations, tensions, etc. The more organized your delivery workflow, the more satisfied the team members will be, and the better the expected outcomes. And we all know that top level executives mainly care about results, so efficient backlog management is the best way towards achieving measurable results and value per enterprise capability.

Rule of thumb: It’s seldom the people who cause project failures, it’s actually a flawed workflow process.

Tip: Improve the process, improve the chances of success.

The Barebones Agile DevOps (BAD) Workflow

I’m proposing what I call a Barebones Agile DevOps (BAD) workflow as a way to help organizations who tend to do a hybrid between waterfall and agile methods such as SAFe. This approach is just a lightweight process for hybrid organizations to streamline the flow of work from the Product Owner to the Architects and finally to the Implementers (Business Analysts/User Story Writers, Developers, Testers, Cloud Engineers, DBAs/Data Architects, Technical Writers). By no means is this approach intended to replace any existing methodologies. It is simply a slimmed down method that is realistic about the ways organizations execute hybrid waterfall, Agile and DevOps. Therefore, this content will not be long, exhaustive, or overly detailed. I’m simply presenting just enough info so that your project teams can rapidly adopt it, in order to reduce and control the chaos in the current IT workflow.

So how does it all work? Every organization has a set of capabilities that support a value proposition to external customers and internal workers. The workers execute certain tasks, which are tied to those capabilities, to deliver a product or service to the customer. Capabilities are often aligned with Epics in Agile, but based on my consulting experience, some organizations struggle in this area.

I won’t address those struggles here. But long story short, there are certain functional business requirements that need to be collected in a Product Backlog. They are usually realized as Epics and Features. Again, Epics are loosely aligned with organizational Capabilities. Conversely, epics sometimes evolve from large user stories, which is kind of a bottom-up approach. The alignment of bottom-up epics to capabilities is a challenge for organizations. The difficulty is in using non agile approaches to identify and map such capabilities to various lines of business functionalities, and finally to IT projects (NFRs, architecture runways, etc.

Figure 2. The 6 Backlog Verbs

The 6 Backlog Verbs

Nonetheless, the barebones approach is focused on 6 verbs to manage the backlogs and push items to the next backlog in the IT workflow pipeline. They are:

Identify

Rationalize

Prioritize

Assign

Deliver

Learn

To explain each, I’ll use the Product Backlog as an example. The other backlogs will follow a similar pattern.

Identify

As digital transformations of organizations sweep many industries these days, the activities of workers to provide value to customers is defined by requests from customers, executives and even workers to improve the various solutions in the enterprise. These requests are captured as functional requirements and queued up in the Product Backlog. Assuming you’ve created a Product Owner team in your DevOps tool of choice (I tend to use Azure DevOps), you can manage these incoming backlog items in a Kanban board, which is useful for rationalizing the items as a team.

Rationalize

At this step, the PO team leader, which would likely be a Product Manager, would organize a regular meeting to go over the new backlog items. Ideally, host this meeting every 1-2 weeks. The purpose is to determine if the new PBI is a new requirement, is similar to an existing PBI, or is not a true requirement but a request for product training or awareness. The goal is to filter out the backlog items so that you’re left with a viable set of functional requirements.

Prioritize

Once you’ve rationalized your PBIs, it’s time to prioritize them based on input from executives and the level of effort to document them. The PO can act on behalf of executives, with Product Managers sometimes weighing in on mission critical PBIs. The level of effort can be T shirt sized like this:

• Small effort
• Medium effort
• Large effort
• X Large effort

If an effort is deemed Large or X Large, there’s a possibility it may align to an enterprise Capability which can then become a basis for an Epic. The goal of this step is to have a better idea of which higher priority PBIs can be assigned to POs and/or Business Analysts. You’ll likely categorize the PBIs into Epics, Features, and User Stories.

Note: Sometimes, when a Solution or Enterprise Architect is involved in prioritizing PBIs, some NFRs (technical nonfunctional requirements) may come up which will be rationalized in the Architect Backlog later. Don’t rationalize and prioritize those in this step. Just label them so that they can be moved to the Architect Backlog.

Assign

Continuing from the last step, the team leader assigns each PBI to the team members based on their current workload capacity. A round robin approach is usually used here, based on my experience with several companies. An even distribution of PBIs is the goal. The level of effort should be factored in when assigning PBIs. An X large PBI might be the equivalent of 4 Small PBIs, for instance. Use a Kanban board to track progress in daily standups (or whatever meeting frequency you choose). For teams of Product Managers and Product Owners, the Product Manager would assign items to POs. Some IT shops also have Business Analysts who work with POs.

Tip: The preceding 4 steps can be done in one meeting or two if team member calendars are tight.

Note: In place of “Business Analysts,” some shops may have “user story writers” or other kinds of roles that work the PBIs into more detail.

Deliver

Finally, each team member works their PBI until it is ready to be delivered to the next backlog in the pipeline. In the case of the Product Backlog, the next one is the Architect Backlog. Since the focus is only on documenting functional requirements in each PBI, backlog items that are T shirt sized as Small shouldn’t take longer than a day, Medium probably 2 days, Large 3-5 days, and X Large up to 10 business days. If needed, break up X Large backlog items into smaller ones to do the work concurrently and deliver it faster.

Learn

At the conclusion of every backlog pipeline should be a meeting to discuss lessons learned. What went well? Where can the team improve? Do we have too many meetings or not enough meetings? Does each team member feel empowered and supported to perform their tasks? Do they feel they can be open and honest with leadership? Use this step as a way to calibrate the backlog workflow to improve the quality and the output of the backlog pipeline. A Scrum Master, Agile Coach or similar leader can facilitate the improvements needed to make this learning step effective.

And that’s it. The next backlog in the pipeline is the Architect Backlog. It follows the same 6 verbs, but from a technical and architecture governance standpoint.

Tip: Any methodology has to feel natural to a team. The waterfall approach, though not always favorable, feels natural to most teams because when the pressure is on, it feels like a natural response. Likewise, implementing an Agile DevSecOps approach should feel equally as natural and easy to learn in order for it to replace waterfall.

The Importance of the Architect Backlog

Interestingly, many organizations overlook the need for the critical Architect Backlog (AB) as they go straight from the Product Backlog (PB) to the Sprint Backlog (SB), incorporating architecture input as an afterthought, or just another task. Bridging the gap between these two backlogs is actually not trivial. Smaller organizations can get away with skipping the architect backlog and letting analysts and developers figure things out on their own (which is the nature of self-organizing teams).

For larger enterprises, this is not an option.

Developers are usually overworked and don’t have time to consider if a PBI is a repeat of something already done, whether it truly makes technical sense, whether regulatory or corporate policy requirements need to be applied, strategic backup and disaster recovery designs, etc. My experience shows that this backlog is just as important as the PB and Sprint backlog, making for a “Big Three” backlog strategy at a minimum.

Solution and Enterprise Architects have to rationalize each incoming PBI to make sure they are technically feasible. They make a best guesstimate as to the level of technical effort involved in doing the high level design. They leave the low level design guesstimates to the Sprint Planning process (basically, the beginning of the next backlog, the developer Sprint Backlog). The lead architect, usually an Enterprise Architect, will assign AB items to each Solution Architect on the team. What is delivered is usually a Solution Architecture Design (SAD) document. This document should not be more than 5 to 10 pages long and should come with a one page recommendations to guide developers as they take this input into the Sprint Backlog.

The Developer Sprint Backlog usually is setup pretty well, from my experience. No need to go into much detail here. With a smooth PB and Architect Backlog, the developers can focus on sizing the level of effort using a Story Points scoring system. Items they deem above average (usually higher than 5 on a scale of 1 to 10) would involve Solution Architects having to approve the code at a DevOps tollgate before it is pushed to the next step in the CI CD pipeline. Architects generally verify that best design practices are being used, and if not why not, also looking for regulatory compliance, corporate policy compliance, performance and other NFRs, etc.

The remaining roles of Testers, Cloud Engineers, Security, Data, have more streamlined Backlogs as they don’t need to be as involved once the technical rigor of the Architect and Developer backlogs have been performed. The main backlog verbs here (steps) are Rationalize, Assign, Deliver and Learn.

Conclusion

Hopefully this scaled down, barebones approach is easy enough to help hybrid environments make the most of their unique mix of waterfall and Agile DevOps. If you think your teams need an outside voice to help adopt this easy approach, feel free to reach out to me. Until the next video, stay agile.

How to Really Map a Namecheap URL to Your Static Azure Cloud Website

You finally buy that cute-sounding website address, and then some time later, you pick a cloud platform to host your website. These days, that’s starting to be a typical scenario. Cloud computing has brought the price of owning your own website down to very reasonable costs. Likewise, with the expansion of website domain addresses beyond the classic “.com” URL, the cost and ease of getting your own web address has improved. But when it comes time to use your shiny new website address you bought at a domain name registrar like Namecheap.com to deploy your website to your inexpensive Azure cloud account, that’s where things get a little tricky.

Both Namecheap.com and Microsoft offer online Help articles to walk you through the process, but not specifically for deploying a Namecheap.com registered domain to a static Azure cloud storage account. Namecheap.com provides generic instructions for routing your URL to ANY cloud provider, and Microsoft offers generic instructions for creating DNS zone settings for URLs registered at ANY domain registrar, but no two domain name registrars and cloud platforms are the same. In other words, once you try to customize the settings for a specific Registrar-Cloud pair, the instructions can be frustrating. This article provides help for making your Namecheap.com URL work with your static Azure cloud website.

You may ask, “why not just buy the URL domain and website hosting from the same company, either Namecheap or Microsoft?” You can certainly do that, though Microsoft, as of this writing, does not sell domain name registrations. If you’ve hosted sites with WordPress or Shopify, you should know how this works. But what if, say six months later, you decide to switch hosting providers or the company goes out of business?

It’s a best practice to have your domain registrar separate from the hosting provider to avoid having one company monopolize your online presence. You can probably apply this help to other pairings, but you will likely encounter some hiccups along the way. But if simplicity is your number one goal, then it might be more convenient for you to have one company take care of everything for you. No need to read the rest of this article. But for those who already have a URL domain registered with one company (in this case, Namecheap.com) and are looking to host a website on another company’s cloud platform (in this case, Microsoft Azure).

Namecheap.com is my registrar, but most domain registrars work in similar ways. Without further ado, I will skip the verbosity and get right to it. The process of configuring your URL to work with your cloud account is as follows:

1. Have your URL domain registration info from Namecheap.com handy

2. In your cloud account portal, setup storage accounts for static websites

3. Configure your Azure cloud account so that your DNS configuration is ready to go with your DNS nameserver

Both Namecheap.com and Microsoft have tutorials to help you (links are provided). I won’t repeat the steps here. I suggest reading that now before continuing. I will focus on the details that are not so obvious that can frustrate you.

Read the rest here!

Tips for Inheriting Legacy Software Code

Photo credit: goran ivos via unsplash

At one point or other, a software developer will be tasked with inheriting another developer’s code. Less experienced developers will not have a clue what’s in store for them, and more experienced developers already know it’s like playing Russian roulette. Ideally, the prior developer did a reasonably good job with writing clean code (not perfect, but clean) and hopefully some inline comments clarifying the more complex, mission critical parts of the solution.

The level of tech debt the inheritors encounter will depend in large part on the age of the code base, which is a key factor in what’s called software rot. Software rot is the idea that, like any other tangible product, software decays over time. The rate of decay accelerates if the code is not continuously updated and deployed. This means there are two categories of inherited code:

Fresh Code

Stale Code

Fresh code will often have the latest libraries and frameworks in place. Hopefully, they follow the latest best practices for mobile and web development. Code written in the modern era of MVC and microservices will likely be reasonably clean enough to understand without much documentation. Stale code, on the other hand, runs the risk of being out of touch with the latest best practices. Code written, say, 15 years ago will have big monolithic services (early SOA era) and some fat UI clients. Infrequently updated code are not as bad as code that has not been updated in a decade or longer. Following DevOps processes ensures the code stays fresh and is easier to inherit.

Read the rest on Medium.com!

Understanding the Relationship Between the Product Owner, Solution Architect and Cloud Development-Deployment Teams

By John Conley

Photo Credit: Mimi Thian from Unsplash.com

Note: This article is also available on Medium.com.

As organizations launch digital transformation projects using Agile and DevOps techniques, it’s easy for them to overlook the dynamic of the teams they assemble to make the transformation a reality. The transformation team needs a technical vision as well as a business vision. Without the clarity provided by the vision, the team can break down into a basket case of ineffective sprints and unproductive relationships. The Product Owner role helps drive that vision into a set of strategic initiatives that then are vetted and technically prioritized, with the help of the Solution Architect, into sprints. Of all the relationships on a given team, the most misunderstood perhaps is that of the Product Owner, the Solution Architect, and the developers and deployers who make the digital solution a reality.

One of the reasons for this misunderstanding is the underestimating of the complexity of a project. With smaller organizations, this may or may not be a big deal. But for larger corporations, especially those that are publicly traded, this is often inexcusable.

Within any organization, there are two figurative sandboxes that employees work in:

• The Business sandbox and
• The Technology sandbox

In the Business sandbox, employees carry out tasks that directly align with the organization’s marketing and business support operations. In the technology sandbox, employees are tasked with ensuring that the best and most updated technology is being used to support the Business sandbox. In a digital transformation, technology is no longer an afterthought, or “those IT nerds over there,” but an essential engine that drives the business forward. For every IT project, the leading voice of the business sandbox is the Product Owner (PO).

Photo: Nesa by Makers at Unsplash.com

For the Technology sandbox, the Solution Architect (SA) is the main voice. The Product Owner, as the voice of the customer, internal employee, and executive stakeholder, has the responsibility to manage a Product Backlog of requests for new features to existing solution, brand new solutions, and bug/defect requests. Since the Product Owner is generally nontechnical (which is usually a good thing), the Enterprise Architecture team assigns a Solution Architect to that PO. The SA and PO meet regularly (usually weekly or biweekly) to go over the Product Backlog (PB) to vet each Product Backlog Item (PBI).

Depending on how large the PB is, the meeting can be either quick or tedious. The latter is especially true for larger organizations who are introducing the concept of a PB for the first time. Vetting a the PBIs in a backlog is a multistep process:

• PO Guesstimate
• SA Guesstimate
• PBI Priority Ranking
• Executive Budget Approval
• EA Backlog

PO Guesstimate

The PO t-shirt sizes (e.g., Small, Medium, Large) the business importance/impact of each PBI based on business strategies and capabilities being addressed. No technical input involved. Sometimes, the PO will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There will be times when the PO needs further clarification on the business rationale for a PBI from executive stakeholders. These can be marked as “Pending further business review” or something similar. These items should be time tracked so that they don’t age too long in the product backlog.

SA Guesstimate

After gaining business insight into the PBI, the SA t-shirt sizes the effort to analyze and implement technologically. No business input involved. The most popular t-shirt sizes used are Small, Medium and Large. Some teams use X Large for really big epics, but that’s up to you what works. Sometimes, the SA will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There are also times the SA may need a second pair of technical eyes to vet a PBI, so these should be marked “Needing further technical review.”

PBI Priority Ranking

If a PBI survives 1 and 2, then the business and technical rankings together should guide the PO and SA to prioritize the PBI relative to the others. Ranking PBIs is mostly subjective, but a good rule of thumb is to give weight to those items that are quick wins or have been heavily requested among users and executive stakeholders for some time.

Executive Budget Approval

Once the PBIs are prioritized, the PO gets budgetary approval of the top 10 (or whatever the threshold is) from executive stakeholders. Once a PBI is approved, the PO marks the PBI as “Ready for Implementation” or whatever status is agreed upon.

Photo: Icons8 Team from Unsplash.com

EA Backlog

There are different schools of thought regarding how to the technology team proceeds after a PBI has been approved. The Scaled Agile Framework offers some good ideas around value trains and solutions trains that have helped many organizations. Plain old Scrum, Agile and DevOps have good ideas here. Choose the approach that works for you. Here, I am focusing mostly on the pure process itself without getting bogged down in methodology wars. Once a PBI is approved, some technology leaders directly assign them to a sprint backlog. That might work for smaller organizations, but for larger ones, there is a need for a technology “brain trust” to determine the next step before it goes to any particular team’s sprint backlog. This is where Enterprise Architecture (EA) comes into play.

Often, SAs are under the direction of an EA Brain Trust who assigns them to one or more IT projects. So it would make since that there needs to be an EA Backlog the mediates between the PO’s Product Backlog and each team’s Sprint Backlog. This becomes especially true for organizations going through a digital transformation that involves implementing cloud computing. In the cloud, there are three layers that a PBI can intersect with:

• Software (SaaS)
• Platform (PaaS)
• Infrastructure (IaaS)

Each of these tiers would have a corresponding technology team of technical development and deployment specialists to implement the incoming PBI within the organizations IT environment. With the typical sprint backlog setup, the default assumption is that the incoming PBI is focused on developing software. But what if it only involves standing up a SQL database or a Linux or Windows Server VM? The determination about what kind of team to engage for the solution needs to be at the EA level. This technology brain trust, the EA Team, should have leaders from each area to help engage the right team.

The PBI would then be routed to that respective team’s Sprint Backlog to work. The EA team would also do a more technical score of each incoming PBI to determine if an SA is needed to guide the sprint team. A good starting point for a scoring system is 1 to 50, where anything 26 or higher means the PBI is strategically important enough to warrant assigning an SA to the team. Less strategic PBIs can usually be handled by sprint teams with just a normal tech lead or dev lead. If an SA is needed, the SA would then work with the team to do normal sprint planning and backlog refinement activities. The SA creates necessary design docs that are within the guidelines of the master EA doc.

Considerations for Consulting Engagements

The process of initiating a consulting engagement for a prospective customer has its own set of steps not unlike a software development project. After a consulting sales pitch, there has to be a customer assessment phase to determine the level of effort both parties can expect before a full engagement commitment is made. Both roles, PO and SA, are needed at a minimum to determine the effort.

During the assessment, the PO and SA develop and manage a backlog of items the customer would need to address before committing to a digital transformation initiative. Depending on the size and complexity of the organization, this assessment can take anywhere from a week or two, to several weeks or longer. The less mature the organization is technologically, the longer this assessment phase will take. It’s similar to when you hire house cleaning service. If it’s your first time, and your house is big, it will take longer than a similar house that already has regular house cleaning.

The successful completion of the engagement setup has, at a minimum, the following micro sprints as key milestones:

• Request for info, quote, proposal from the prospective client
• Sales pitch by the consultant
• High level needs assessment by both the client and consultant
• Service Level Agreement (SLA)
• Product backlog creation and evolution based on user stories and other feature requirements

This set of milestones is by no means exhaustive but is meant to provide a set of guardrails to manage the micro sprints for the engagement setup process.

Wrapping Up

Hopefully this white paper helped in understanding the important relationship between a Product Owner and a Solution Architect. The former is business oriented and is the voice of the customer, employee user and executive stakeholder. The latter is technically oriented, and is the voice of the technology teams and the mediator between the functional requirements (usually user stories and other PBIs) and the nonfunctional requirements that the technology teams implement to satisfy the business. The EA team helps determine how to map incoming PBIs to the right technology teams, and will assign an SA if the PBI is architecturally and strategically significant.

About the Author

John Conley is a Dallas, TX, based Digital Solution Architect and Cloud Engineer Consultant. This is an excerpt from his forthcoming eBook “2020 Business Guide to Digital Transformation Governance.” Feel free to reach out to him if you have any questions or need consulting for your enterprise engagements.

How to Properly Plan Your Website Before Launching It

 

The importance of knowing your business processes before hiring a web developer is essential. Documenting the steps you take to engage your customers, suppliers, employees, investors, lenders and government agencies are important. This means you have to properly plan every step of the way from where you are now, to where you want to be. You have to answer questions like:

1.       How do I reach out to the public to convince them to become paying customers?

2.       How do I want my customers to learn more about my business?

3.       How can customers read about my products or services before buying?

4.       How can I convince customers to make the buy decision?

5.       How can I make it convenient for customers to pay for my products and services?

6.       How easy is it for my customers to understand my refund policy and actually request a refund?

7.       How can I work with my suppliers to make it easy to buy their products and services I need for my business?

8.       How easy is it to resolve my customers’ refunds when I need to get reimbursed from suppliers? Do my vendors make it easy for me to get such refunds?

9.       How will my business continue if a disaster happens or if a supplier I rely on goes out of business?

10.   How do I get the necessary licenses for my business from the local government agency (if required)?

11.   How do I pay my business sales and income taxes online?

12.   If I have employees:

a.       How do I manage my workers HR and payroll needs?

b.       How do I make it easy for workers to perform their tasks easily?

How do I keep investors and lenders informed about the performance of my business?

View the entire video for helpful, informative tips on getting your website up and running today!

 

How to avoid getting ripped off on website development

Every so often, I’ll come across someone who had bright eyed dreams about launching a website as part of their business plan, only to have those dreams go down in flames because someone they trusted with their hard earned money failed to deliver the desired website on time, if at all. The average losses they suffered in terms of websites that were half done or poorly done has been about $400-900. How could this happen?

The problem comes into play due in part to greed on behalf of the website developer, and lack of knowledge on the part of the customer. Usually, the potential customer asks friends for referrals to web developers or they post on the various social media sites looking for someone. Without doing much research, they pick a developer who sounds convincing and seems “technical.” The developer charges anywhere from $250 to over $1,000+ to do the whole website without providing a lot of details about what’s all involved. They usually pressure customers to pay the entire amount up front. A few customers try to negotiate a lower fee or pay half as a deposit, promising to pay the other half when the site is complete.

Regardless of what price is negotiated, the outcome is often the same: The developer starts on the site, putting up a web page or two, adding some photos and text, and few social media links here and there, and then poof! They vanish. The customer tries calling, but no answer or the number is disconnected. Hundreds of their hard earned dollars gone and they’re ready to sue.

But wait. Is there anything you could have done differently to avoid losing so much money?

Yes! The first step is to make sure you have a reasonable business plan to go along with your website. Surprisingly, most website customers downplay this step, thinking all they have to do is upload a few photos and a contact page with an about page explaining what they offer, and that’s it. No! Your website is a reflection of the business processes you want your customers to be able to do using your website.

For instance, if you are a hair stylist, you may want customers to book appointments, look up and select various hair styles, order hair, manage the way they pay you, allow customer reviews, etc. By not outlining these features up front, you increase the likelihood of misunderstandings between yourself and your website developer. This, then, leads to you feeling like the website is not complete, and the developer might get frustrated and walk off. This is not to say that there are no bad website developers (there are), but in this specific scenario, failure to describe the features of your website along business processes will increase the likelihood of misunderstanding.

Second, research potential website developers. Remember you get what you pay for, so if someone is offering to do your site for a ridiculously low amount (like under $100 total for a full website), chances are it might be a bait and switch scam. Three to five years’ experience should be minimum for the best quality service, although that’s not to say anyone with less experience would be that bad. But it takes some years to get into a rhythm in website development. My company, Samsona Software, has been around since 1993, so I know something about longevity and consistent customer service.

Finally, know that there is a difference between a website designer and a developer. Designers are usually focused on creating web pages and making them look good from a visual appeal standpoint. Website developers go deeper than that:

1. Hooking up your pages to databases
2. Integrating with cloud computing platforms such as AWS and Azure
3. Integrating with eCommerce platforms like Shopify, Magento and BigCommerce
4. Implementing microservices to harness the power of various business features unique to your industry. This latter one is part of my offering to my larger business customers.

If you get a chance, try an initial consultation first before seeking help building your website. I can help with that, or anyone with serious experience in this space can do an initial consultation to help you get to where you want your business dreams to take you.

About the Author

John Conley is a technology and digital transformation consultant for Samsona Software Co, Inc., based in Dallas, TX. His service offering is focused on enterprise and solution architecture, as well as small business solutions. Feel free to contact him for your business technology needs.

The Idea of Business Enabling Microservices

As digital transformation sweeps the business landscape, executives and managers are rethinking their business processes. This paradigm shift is important because technology is the lifeblood of industry, the economy and even society at large. People are becoming more comfortable living their personal and business lives primarily through mobile devices, laptops as well, and less so on traditional desktop PCs. Wearable technology, a relatively smaller niche in the overall ecosystem, will eventually compete with today’s mobile devices for digital hegemony among users. But what will be common among all of these ways of conducting business through technology is the need to design components to automate business processes.

As of today, these components are usually realized as microservices in the cloud.

I’ll avoid getting too technical about microservices. Just know that microservices are atomic processes that work together to provide a business solution to a business problem. What that means is that each business process, when well defined, is kinda like a worker just like any other human. Of course, a microservice is very limited to its prescribed business task, minus the distractions that we humans have in our personal lives.

How might this automated worker be visualized for the busy executive to understand? Imagine a bank that offers three account products to the public:

 

1.       Savings Maximizer

2.       Checking Plus

3.       Secure Safe Deposit Box

 

Many years ago, in the age before modern automation, the bank would hire specialists in each of these products to manually offer and maintain these kinds of accounts. The workers would use what was called “ticklers” (like paper ledgers) to keep track of account info. With advances in software technology, managing such banking products became more automated. But in their simplest forms, how might we come up with software components for these products? Figure 1 shows one possibility.

Though the three services look cute in blue against a white background, they can’t sit in isolation. They must do something meaningful to deliver real business value in a way that enables executives and managers to then manage the impacted value chain. In a nutshell, our microservices must do the following:

 

1.       Get data from or display data to the user (knowledge worker, the primary persona)

2.       Execute a workflow on behalf of a user

3.       Get data from or save data to the on prem or cloud database/data lake

In other words, a human user has a certain business objective that the microservice must fulfill, and that microservice needs a dedicated data store to manage the critical business data it needs to satisfy the user. Figure 2 shows the end to end context that supports this flow of business data from the user to the data store.

Ok now that’s a little better. The microservices have end to end context, with the users on the left and the solution tiers to the left. The users only know about the bank app, which governs their user experience (UX). From a business perspective, it would be important to hire technology partners who can pair the UX requirements with the technical plumbing to identify and locate the right microservice for the given user story.

Notice that each microservice has a link to their own databases. This is a fundamentally important part of microservice design that allows the independence of business components, making ongoing development and maintenance cost effective for your organization. If a database goes down for whatever reason, the bank app still have access to the active databases without impacting the user experience.

What’s missing is the fact that each of the microservices can communicate with each other directly (usually by JSON messages) without need to directly access each other’s databases. Also absent is the fact that microservices are usually deployed in the cloud in containers, which encapsulates much of the platform configurations needed to keep the component independently maintainable from a system maintenance standpoint. These cost savings positively impacts the bottom line of the each business product, allowing your organization to in turn pass the savings on to your customers, giving you a competitive advantage. Hopefully as an executive sponsor or manager, you can begin to incorporate microservice thinking into your overall digital transformation strategy.

 

About the Author

John Conley is a digital transformation consultant for Samsona Software Co, Inc., based in Dallas, TX. His service offering is focused on enterprise and solution architecture, as well as . Feel free to contact him for your business technology needs.

So Python Finally Beats Out Java

With Java having become so popular among professional, enterprise developers, one would think it would reign supreme among techies. But with the fast rise of Big Data and Cloud Computing thanks in large part to Apache Spark, Python has edged out Java as the most popular development platform, according to a  comprehensive 2019 StackOverflow.com survey. Another interesting fact is that when it comes to learning the latest and greatest technologies, almost 87% of professional developers say they are self taught without taking a formal course. Read more here…

A Simple Technology Game Plan for Entrepreneurs

You have a vision of providing a unique product or service to the world, but that pesky little thing called technology is just standing in the way like a big bouncer at a trendy, popular nightclub. If you could do it yourself, you would do it in a heartbeat, but there’s only so much available time, especially if you have a day job working for someone else. You finally decide you need help from a trusted, reliable and affordable technology partner, but even the process of finding someone is not as straightforward as you wish.

Here’s a simple approach for finding help.

The very first thing you want to do is describe what problem you are trying to solve. In other words, what is so special about your product or service that will solve a problem for the target audience? If you don’t have this articulated up front, then coming up with a technology game plan will be useless. Every entrepreneur is trying to solve a problem that certain segments of the population are dealing with, and of course, entrepreneurs want to be financially rewarded for the solution. Identifying the problem translates into the mission statement of your business plan. You describe the problem in a plain English document called a Problem Statement. The question that is the basis for your Problem Statement is, “What problem am I trying to solve with my idea?” The statement does not have to be anything fancy. Just remember the problem should be written from the perspective of your potential customer (also called “Voice of the Customer” in popular business process methodologies). The problem statement from the Customer’s view might be as simple as one sentence that says something like, “I  have a problem keeping track of how many calories I eat and how many steps I need to walk to burn those calories each day.”

Once you describe the problem you’re trying to solve, it’s time to state what you think the solution to the problem is. If your product or service is the solution, then describe how it addresses the problem. So continuing with our Problem Statement, the Solution Statement might say something like, “As a Potential Customer, I  want a mobile app for my smartphone that tells me how many steps I need to walk in order to burn the calories associated with the food I ate each day. I want to be able to enter each food item as part of the solution.”

That’s it. Once you have the Problem and Vision for the Solution documented, you can then search for a Technology Partner to help you make your vision a reality. Having a website is a key tool for every entrepreneur who needs to market the vision to the public. You can view a video I created earlier this year for 50Plano.com to help with the website process.

Note: Bookmark this page and follow us to keep up on the latest updates to this and other articles!

 

How to Write a Technology Game Plan for IT Projects

These days, a growing number of companies are adopting techniques from IT (Information Technology) world for solving common problems. For instance, some of these companies are adopting the use of version control for non-technical documents and other objects of collaboration in the workplace. Another technique more companies should adopt is the documenting of solution proposals for non-technical problems. In IT, the use of Solution Architecture Documents (SADs) is common when translating non-technical requirements into a technical specification that can be executed by downstream tech partners. Unfortunately, too many SADs have become very impractical, bloated, and often uncomfortable to work with because the accompanying templates (whenever you can find them online at work) are painful to use and often get in the way of creativity and innovation. They are also kept separate from the user requirements document, creating confusion as to what items belong in which document. In essence, the current and varied formats of SAD documents have become a problem in themselves and usually end up gathering electronic dust in some SharePoint or other collaboration site folder.

That’s not very innovative.

With companies like GitHub turning on its head the notion of old-school corporate bureaucracies, it’s time to put away old-school approaches to proposing solutions. The idea of simplifying requirements gathering is nothing new, not even in IT, but creating a collaborative solution proposal process with a simplified, comfortable approach is new for Solution Architects – or shall I say, Solution Coaches. Perhaps replacing the expression “Solution Architecture Design” with “Technology Game Plan” is more fitting with the role of a Solution Architect, who really is a solution coach.

In every work context, workers encounter problems that need solutions. That’s normal and expected. Identifying these problems and proposing solutions to them should be painless and easy to document because both functions, identifying the problem and proposing a solution, lead to innovation. A technology game plan is needed to realize the solution, and every game plan requires a team where each player has a certain role to play. It is up to the Solution Coach to come up with the best game plan for be victorious. Each team member, called generically a Solution Partner, should be specialists in their respective field. There is a Coding Partner, a Data Partner, a Security Partner, Testing Partner and an Infrastructure Partner. A Management Partner covers the usual role of a project manager, but can also be an executive stakeholder or sponsor.

The Technology Game Plan should be formatted to have section geared towards each partner. This is important because current Solution Architecture Design templates have archaic sections broken down by logical, physical, constraints, assertions, etc, that are not always obvious upon first glance. It’s better to have a clearer document the is more direct in terms of which sections belong to which partners to execute. Imagine a sports game plan with a logical and physical section. Which partner is logical? Which one is physical. In my experience, on project after project over the years, the same questions always comes up: “Which section belongs to me? What does logical mean? What is physical?” So a simpler, more direct outline should look something like this:

Technology Game Plan

The Problem – Can be a link to an external document or the actual verbiage added here. Should be plain English with a complete thought per sentence and a noun-verb-noun format where the actor, persona or system is obvious. Should be no more than a paragraph or two.

The Vision –  Can be a link to an external document or the actual verbiage added here. Ideally, should be articulated in the form of a user story or use case.

The Solution – What’s the game plan for each team member (or solution partner) to solve the problem according to the vision outlined by the key stakeholder? More on this section in a bit.

Before there is a Vision, there has to be a Problem to be solved by the Vision. Just a simple description of the business problem is needed, as mentioned above. If your business is being fined by the government for failing to respond to certain customers in a timely manner, then describe how the current system or business process is failing. This is where approaches such as Lean Six Sigma comes into play as they drill down to the root business problem by asking a series of cascading “why” questions.

The question to be answered for the Vision is “How do I want the solution to solve the business problem?” A good way to envision this is to imagine you bought a robot and you wanted to tell the robot what you want it to do to solve the problem without getting into technical detail (the robot can handle the details, it just needs for you to speak the verb command and what outcome you expect when it is done executing your command). So you might tell the robot “As a stock analyst, I want you to gather all the top 100 stocks in the U.S. and display the data in a visually appealing way that supports my decision making.”

Every problem does not necessarily require the same set of Solution Partners to solve them. Some problems are repeatable while others occur for the first time. Sometimes a worker (aka Problem Partner) may not know that a problem they’ve identified was already solved before. Even these problems should be documented because it may point to a lack of available online training or mentoring. The solution in such cases is very simple. But the fact that the Problem Partner brought up this problem is evidence of that worker’s ability and willingness to innovate at any level, and the Solution Proposal becomes evidence of their desire to be creative. It’s good to encourage that because if makes the worker more comfortable to identify even more problems and, thus, to spark innovation.

As mentioned in another article, software design principles borrow heavily from a non IT source: classic architecture. When an architect designs a building, he or she is solving a problem and take into account what we now call “user experience” (aka UX). In other words, when a person enters a building, what is it that the owners of the building want them to accomplish? What problem is being solved? With a home, there are many problems being solved, such as the need to cook food, sleep, use the bathroom, be protected from the elements, be cool when it’s hot and be warm when it’s cold, etc. Each of these problems has a solution that does not require the same Solution Partner. For instance, to install plumbing, you don’t need a Solution Partner who installs windows. Thus a window installer does not need to provide input into the Solution Proposal. This is natural, and the Solution Proposal should reflect that natural simplicity.

In its simplest form, a Technology Game Plan can just contain a Problem Description and a Vision Description if both the problem and solution are simple. In the Agile world, this is the best approach as it lends itself to the developer working directly with the stakeholder to solve the problem quickly. More complex ones might require a bit more info, but certainly not too much that the partners lose sight of creativity. A new age Solution Proposal for more complex solutions might have the following minimal elements as a starting point:

1. What is the Problem and how do you think the Solution should address the Problem?
   1. Problem Partner 1
      1. Problem: [Describe in plain English when possible, including jargon and acronym definitions]
      2. Solution idea: [Try not to get bogged down in technical details, just describe in plain English as if, for example, you were telling a robot what you want it to do for you]
   2. Repeat for each Problem Partner
2. Given your input, here’s how the Solution can best address the Problem:
   1. Solution Coach:
      1. The Solution Proposal
         1. Context Diagram with explanations for each component or role
         2. User-friendly description of how the Solution solves the Problem
         3. Repeat if there is more than one proposed Solution to the Problem. Be sure to include a Solution Comparison (discussed later)
      2. Any general risks that might hinder the solution from being delivered on time and within budget?
      3. What Solution Partners will be needed?
      4. Is a Problem Coach needed?
   2. Solution Partner 1
      1. Diagram if any
      2. User-friendly description of how your part of the Solution solves the Problem
      3. List any security or other risks specific to your contribution and how they are to be mitigated
      4. Any legal, regulatory or corporate policies apply to your contribution? If so, list them briefly and add any online links to details
      5. Attach any necessary documents to explain the process you will use to solve the Problem
   3. Repeat for each Solution Partner as needed
3. Any other legal, regulatory or corporate policies apply that have not been identified? If so, list them briefly and add any online links to details
4. Approval Signatures if needed

Notice that in the Partner sections, there is a dynamic section that can scale to accommodate any number of Problem and Solution Partners. Also, as with any sports teams, the head coach (Solution Coach) may need assistant coaches (Problem Coaches) to ensure that all work (done by Problem Partners under them) needed to articulate the Problem is done effectively. Usually, only a Problem Coach is needed to document most business problems, but some complex problems may require Problem Partners to do some leg work in a particular area of the problem.

Implementing some solutions may not require sections 3 and 4, depending on the nature and scope of the problem. Be sure to ask key decision makers at your company if the proposed Technology Game Plan might incur any level of compliance issues or risks.

Some Technology Game Plans will require signatures from decision makers in the organization, depending on the level of complexity in delivering the solution. The Solution Coach should work with either the Lead Problem Partner or an Executive Sponsor to determine if signatures are necessary. It is good not to burden the Problem Partner with seeking signature info so as not to stifle innovation and creativity.

Let’s go over the roles.

Solution Proposal Roles

Problem Partner

This worker is the one who noticed a problem and was inspired to find a solution to it. This is how innovation starts. Some problems may have more than one worker who collaborates to identify the problem and have separate but dependent ideas for solving it. This is typical in workflows. In such cases, it is good to have a Problem Coach who champions the cause on behalf of other problem partners. This keeps from having more than one worker bottlenecked in the day-to-day details of working with the Problem Partners to come up with a solution. The Problem Coach can keep the other problem partners updated on the solution’s progress and also gather updates from these same partners when they come up with other ideas or provide clarity on existing problem descriptions. The Problem Coach can be a project manager and probably should have some experience managing projects.

Ideally, the Problem Partner should not describe the Problem or suggest a Solution Idea in a manner that is too heavy with work jargon or acronyms. Instead, a good technique for suggesting a Solution Idea is to imagine your manager or team leader purchased a robot to be your assistant. What would you tell the robot to do in order to solve the problem? The only rule in communicating with this Imaginary Robot is that it does not understand workplace jargon, slang, vernacular or acronyms. It only understands plain English commands. Finally, keep in mind that you are not necessarily the expert in solving and delivering every aspect of the problem (unless you’re truly gifted in multiple areas and the organization hired you as such). By fine tuning the way you describe the Problem and Solution Idea this way, you minimize that chance that a Solution Partner misunderstands your innovative ideas.

Some readers may say, “I don’t want problem partners explaining the solution because they might get bogged down in the delivery details.” Although this has been a long-held rule of thumb in IT, the fact of the matter is that problem partners always imagine the solution, whether you forbid them or not. In practice, requirements have always suggested solution ideas, and problem partners feel the need to convey their innovations and desires as they come to mind. Sometimes it’s difficult for workers to explain a problem without also explaining how they might solve them. The trick then becomes to allow them to express them using the Imaginary Robot technique described in the previous paragraph.

Problem Coach

A Problem Coach coordinates all work, including research and business process analysis, to help finalize the Problem Statement, and may even help with the Vision Statement if the Executive Sponsor is busy. Such a worker must work with a Solution Coach and Executive Sponsor to ensure that the organization can deploy enough resources to realize the vision. This aspect of enabling solutions must be kept separate from the process of identifying the problem in order to not burden workers with implementation details.

This worker can, in certain complex contexts, fulfill much of the same responsibilities of a traditional project manager, minus the bureaucratic overhead of some heave project management disciplines. The idea of a Problem Coach is not to manage a project, but to enable innovation. Unfortunately, there is a big difference between the two. With classic project management approaches, the idea is to tell team members what they can and cannot do, and if someone gets out of line, the PM escalates the problem to higher ups, who in turn disciplines the perpetrator. This paradigm is not a way to enable innovation.

Not all problems require a Problem Coach. Simple or trivial problems sometimes only require only a few minutes to solve (such as granting permissions to a resource, replacing an allergy-causing ingredient in a food dish, or adjusting an accounting entry). Each organization should come up with a set of criteria for determining when the complexity of delivery a solution requires a Problem Coach and even a Solution Coach. A discussion on “Determining the Complexity of a Solution Proposal” is later.

Solution Coach

This worker is the brains behind the Technology Game Plan. He or she can be a permanent employee or temporary consultant and is usually an expert in solving and designing problems. A Solution Coach need not necessarily be an expert in a particular business process, technology or industry as this role is responsible for understanding the Problem and lining up Solution Partners to deliver the best Solution. The Solution is composed of business process components or system components, with workers either triggering the process or waiting for the outcome of a scheduled process. The Solution Coach should have an Executive Sponsor (or similar role) to work with to ensure the solution is in line with corporate design guidelines and expectations if necessary. It is important that the process for providing a solution is not unduly burdened with bureaucracy, only enough to meet regulatory, legal or other compliance if the solution rises to that level. If not, then don’t introduce such overhead.

Solution Partner

An expert in delivering an aspect of the Solution. For instance, in IT, a software developer creates or updates a software application, or an enterprise architect might design a component that can be used by dozens of IT projects. Outside of IT, a marketing professional may design an advertising creative. An HR professional might streamline the hiring process. A housing construction supervisor might replace a problem contractor with a better one. The Solution Partner can be a permanent employee or temporary consultant. This last fact is important because too many companies are not strong in IT operations, so this approach to Technology Game Plans facilitates allocating workers when needed in order to solve a problem.

Executive Sponsor

This worker has decision making authority to enable the solution to be designed and delivered if the problem was determined to be of sufficient complexity to have the need of an Executive Sponsor. Ideally, innovations are best realized in organizations that are not rigidly hierarchical. Obviously, for a lot of organizations, bureaucratic hierarchies cannot be avoided, so the Executive Sponsor should create an Innovation Incubator (aka Solution Bubble) that shields the Problem and Solution Partners from as much of the outer bureaucracy as possible. The Executive Sponsor, then, becomes a protective shield for the team, much the way the Façade design pattern works in IT (for those in the IT industry who know about design patterns).

Such an approach is also a good transition strategy for organizations wishing to shed older hierarchical patterns with newer “open collaboration” approaches that encourage innovation. In legacy hierarchies, regular workers feel inherently inferior to managers and executives, some of whom often come across as unapproachable and distant. Sometimes the higher up leaders even have offices that look intimidating. Workers feel they can get bad performance reviews or get fired for any number of reasons, some of which may or may not be valid. But the overall psychological effect is that workers see these as negatives, and as a result, they tend to avoid innovation just to avoid being fired.

This negative vibe is not good for identifying problems and delivering solutions to those problems.

An article in Fast Company about Open Collaboration quoted GitHub CEO Tom Preston-Werner as comparing GitHub’s org structure to a “neural network , where you have nodes in a graph and then connections between them, and they go everywhere. Everyone talks to anyone.” This is a perfect way of viewing how an organization that encourages innovation should potentially be viewed. (Scientists who work with the brain should also enjoy the analogy). When we think thoughts with our brains, neurons and synapses come alive to carry out whatever action is necessary for whatever triggered that thought.

Determining the Complexity of a Technology Game Plan

In everyday life, some problems are more complex than others. For instance, when a light bulb goes dim at home, you just go buy another one and screw/plug it in. When your car runs out of gas, you go to the gas station and refill it. When you feel hungry, you go and eat (unless you’re worried about your beach body – just kidding). These Single Step Problems would get a Complexity Score of 1 on a scale of 1 to 10, where 1 is simple and 10 is extremely complex. Some problems, however, require multiple steps. For instance, a problem that many Chili’s restaurants have solved is the problem of paying your tab at the end of your meal or happy hour. Instead of waving for a server or bartender, you can now just swipe your card at the table to pay for the bill. It may sound simple to the Problem Partner (the Chili’s customer in this case), but for the Solution Partner, there are multiple steps involved in making sure the tab is paid properly: the user interface of the device has to present the receipt with the accurate line items, the card swiping feature has to capture the payment info from the card, the device has to submit the payment to the bank card network for authorization, the card network then has to debit and credit the proper accounts (Chili’s and the Customer’s) in a secure way, etc. So the complexity of this Solution would subjectively be 8 to 10. A Solution Coach and Problem Coach would be necessary.

Every organization needs to come up with a weight/ranking system to determine complexity. For some, a scale of 1 to 10 may not be enough. Maybe you want to instead add 1 for each step it takes to implement the solution, giving you a bit more concrete metrics. Some organizations may not be so objective, satisfied with just a subjective 1-10 ranking system. Whatever ranking system is chosen, it is good to distinguish at what level a Problem Coach and a Solution Coach is needed. As a starting point, on a scale of 1 to 10, you might want to only bring in the two Coaches if it’s 3 or higher.

What to Do If There’s More Than One Proposed Solution to a Problem?

There are times when problems of a certain complexity will lead to more than one possible solution. For instance, borrowing from an earlier example, if a light bulb goes out at home, you can either get another light bulb, or get a candle or flashlight or lamp. With the Chili’s restaurant example, Chili’s might have chosen between more than one device vendor for their table side kiosk. In such cases, a Solution Comparison might be necessary if the solution’s complexity is sufficient enough to warrant it. Earlier, there is a section under Solution Coach which allows for more than one proposed solution. If the solution is considered trivial (a score of 1 or 2, for example), then the choice of solution can be informal. It is best to just list the choices and identify which one was chosen and why. But for more complex solutions, your organization may desire a more formal analysis of the decision.

Enter the Solution Comparison table:

Common Tasks	Necessity Score	Solution 1		Solution 2
		Quality Score	Notes	Quality Score	Notes
Task 1
Task 2
Total

When preparing a Solution Comparison, remember that every Solution has to fulfill one or more tasks for a given problem. In the workplace, a solution might span multiple tasks in a workflow process. At home, a solution might include multiple tasks, such as painting a wall using faux painting techniques. In IT, a solution might be a web application that has multiple features (similar to tasks), each of which may require a component that multiple software vendors offer. All Partners should work together to come up with a list of tasks to compare the Solution Choices by. For the purpose of the Solution Comparison, try not to make the comparison task list too long to avoid paralyzing innovation. Although a complex solution may encompass hundreds of tasks, you can generally get a good feel for a Solution Choice by comparing no more than 20 tasks or features; if a choice has the highest quality scores for 20 tasks, then it stands to reason that it will probably be the highest for the next 80 tasks. With this in mind, when choosing the list of tasks to compare, be sure to pick the Top 20 with the highest Necessity Scores if you have more than 20 tasks or features.

To arrive at a score for each task item, it is good to meet with all Partners (Problem Partner, Solution Partner, Coaches, and Executive Sponsor if available) to provide the most quality to the scoring effort. One partner, ideally the Solution Coach, can do the scoring if no one else if available, but particularly the Problem Partners will likely have the best understanding of the tasks being compared. If the solution is technical, then it would be good to have the necessary technical Solution Partners evaluate the solutions along with the Problem Partners.

A Quality Score is a subjective number from 1 to 10 that indicates how confident you are the proposed Solution Choice can fulfill the requirements of the given task. 1 is low confidence in the choice, and 10 is absolute confidence. A Necessity Score is a subjective number from 1 to 10 that indicates how important you think the task is compared to other tasks. For instance, borrowing from our light bulb replacement example, you might give a candle a Quality Score of 3 since lighting is generally limited, and a Necessity Score of 1 since you value the other choices more. (But then again, if your problem revolves around having a romantic dinner at home, both scores may be higher because you’d value candlelight over other forms of light when it comes to dating).

To borrow from our Chili’s example, the table kiosk device might have multiple vendors competing to provide the solution to the restaurant chain. The following table provides some example values for illustration using two make-believe vendors (DiningKiosks.com and Table Devices, Inc):

Common Tasks	Necessity Score 1-10	DiningKiosks.com		Table Devices, Inc.
		Quality Score 1-10	Notes	Quality Score 1-10	Notes
Display the menu	10	5	Wasn’t impressed	8
Allow customers to easily choose menu items	10	8		9
Quickly route menu selection to cook	8	9		10
Allow customers to easily request the bill	10	6		9
Allow customers to easily review the tab	8	8		10
Allow customers to easily swipe a card	8	9		10
Securely send the Customer’s card info to bank card network	10	7	Needs better encryption	10
Securely receive authorization and confirmation details from the bank network	10	8		10
Display successful or unsuccessful payment confirmation to the customer	10	10	Good display of line items	10	Great UX
Total	84	70		86	Clear winner in our opinion

As you can see from the table, after assessing each vendor per task item in the leftmost column, Table Devices, Inc. beats DiningKiosks.com easily. With this number in hand, the Executive Sponsor can feel quite confident that a reasonable, good faith effort was made by the team to arrive at a consensus about the best solution choice for the problem.

Next Steps

The goal of this paper is to make sure you have enough tools on hand to solve the world’s problems…well, maybe just the problems in your world. Whatever problem you encounter in the work place, this paper hopefully provided you a minimalist tool to propose a solution to it without being held back with heave methodologies or stifling overhead. Although my background is in IT, I am also a business process thinker and have been solving problems abstractly for many years, especially in the Financial Services, Telecommunications, Hospitality and Healthcare industries (among others). Those organizations that are dedicated to coming up with improved hierarchies that encourage innovation should use the Technology Game Plan (TGP) approach describe in this document as a starting point. The first problem that organizations with legacy hierarchies can solve is how to make the organization encourage instead of stifle innovation. The Technology Game Plan approach should be easy enough to execute immediately without an outside consultant, but if your team or organization needs some outside prodding (and it’s needed in political environments), let me know today by using our Contact form.

John Conley III

You can also download the PDF here: How to Write a Technology Game Plan for IT Projects

©Copyright 2017 By John Conley III. All rights reserved.