In Part I and Part II of this series, we discussed the imperative to modernize your web framework and helped navigate the daunting number of options available. At this point in the journey, you should have done your research, narrowed down the options to a short list with a front-runner in mind, and hopefully started the internal conversations to get other stakeholders on board. In this final entry, we will discuss the final selection, implementation planning, and running and evaluating a successful proof of concept.

Finalizing a Decision

There are a lucky few readers who work for organizations where decisions are swift, they stick, and management is able to focus on execution. Feel free to skim through this section while the rest of us envy you (no gloating, please). For everyone else, a few points of advice:

  • A refresher on stakeholder management is a good idea before beginning a large decision process.
  • Keep your list of success criteria handy any time you enter a discussion with a possible stakeholder. Not only can it disarm resistance, but it can become fodder for negotiation by incorporating the stakeholder’s interest into the success criteria. This is especially useful for latecomer stakeholders with concerns that (at least to you) seem peripheral or barely relevant.
  • A helpful technique for handling individuals concerned about the direction (whether their concern is sincere or cynical trolling) is to remind them of “lowered” stakes of the decision. At this point, we are selecting a technology for a proof of concept. If it fails, we will fail fast and give the concern troll his “I told you so” moment.
  • These days it is fashionable to make technology decisions lower in the ranks of the organization and by team consensus (we may have Agile to thank for that). Teams should embrace this and use a solution selection matrix to facilitate the decision and show visibility to senior management.

Preliminary Planning

I encourage large organizations to start this process by mapping out initiatives that are adjacent to, similar to, or have dependencies with your web framework adoption initiative. This exercise also affords the opportunity to fine tune your success criteria, making sure they are clear and realistic. I’ve seen organizations adopt new technology in a quixotic attempt to fix broken processes, organizational dysfunction, or cure technical debt; of course these efforts always ended in failure.

Few organizations are good at multitasking, but those that are have a nuanced understanding of the drivers, dependencies, and possible areas of resource contention or other conflict. The relations diagram (sometimes called interrelationship digraph) is an excellent tool for analysis and management consensus building. Participants brainstorm all the related initiatives, issues, and outcomes–one per sticky note or index card–and then discuss and determine precisely how they are related. Your organization could be in need of a UI overhaul, but concurrently you may be adopting a new development methodology, migrating to cloud infrastructure, retiring a legacy system, and on-boarding a large and difficult customer. Every organization will differ on how these are related to each other, as well as how they are related to desirable and undesirable outcomes. Once you reach consensus on how these are related, you need to use that understanding to establish “rules of the road” to keep traffic flowing freely and initiatives less likely to crash into each other.

Proof of Concept vs. Pilot

Discussion of success criteria is incomplete without giving some thought to the parameters of failure. Skip the tiresome navel gazing over the virtues of failure and get pragmatic: design a one-stage or two-stage plan to prove the new framework on a small scale, developing real software in real-life conditions, enabling failure on a small scale and learning to be applied to the subsequent stage. (To draw an analogy, or for inspiration, consider the sequencing of the early Apollo missions.) A single-stage proof of concept may be sufficient for small to medium sized implementations. Large-scale or high risk implementations may consider a proof of concept followed by a pilot. With either arrangement, consider these design points:

  • A proof of concept should have modest scope and short duration, perhaps a few weeks. A pilot can be longer but should be subdivided into sprints or other units, each with clear acceptance criteria.
  • Just as a good test environment needs to mirror a production environment, a well designed pilot project should mirror the real deal: use the same personnel, development methodology, Dev Ops tools, back end, APIs, etc.
  • Beware the risk of too many FOAKs (first of a kind). You are trying to prove a new technology in an existing environment of people, processes, and other technologies. Think of each of these as a variable, wherein a well designed experiment limits the changing variables. Too many FOAKs increases the risk of failure, but more to the point, it also confounds your ability to determine why it failed.
  • Use a structured process for evaluating the success or failure of the POC or pilot (quantifiable is always preferable but not always possible), looking first to the implementation team for their feedback. They should be the first to apply learning to the next phase.
  • The outcome of the POC or pilot should be creating meaningful software with real users and real value for your organization. It should not be a boiled ocean, nor should it be an academic exercise.

Teaser: Planning for Talent

What was once the shortage of technical talent in Pittsburgh has escalated into a talent war. With new frameworks and languages exploding on the market faster than candidates can fluff their resumes with them, will employers need to resort to the nuclear option? Watch this space for new posts.

Implement and Sustain

Following a successful pilot comes implementation of your first full-scale project in a new web framework. But what happens after that, and what’s the end game? To answer this question and make long term plans for your organization, consider these two assumptions followed by a conclusion. First, a newly adopted web framework will have a relatively short lifespan in your organization. The staying power of mainframe is legendary, and perhaps Java comes in second place (possibly a distant second). In 2019, it is unrealistic to expect that today’s web framework will incrementally replace large portions of your legacy software. However–and this is the second assumption–the business function your software supports will probably outlive the software you develop today. Until the day comes that today’s software is replaced, it needs to be stable, scalable, and supportable. Having these qualities should not require you and your successors to run the hamster wheel of constantly upgrading to the newest version of the framework. Instead, plan for an intermediate lifespan and make its supportability an outcome of good design and good software practices, not a factor inherent to the framework itself. You cannot control what the industry does with the framework you chose, but you can and should take control of what and how you develop with it.

As we’ve examined in this series, there remains an ever-expanding array of framework options, but also the responsibility to respect cost, quality, and time. Don’t get overwhelmed! If you need guidance in your decision-making process, let the Rivers Agile’s team of experts help you with strategy, implementation and beyond. Contact us today!