Month: May 2024

|In: Uncategorized|Last Updated:

By way of introduction for some of our readers, Memorial Day is the unofficial start to the American summer holidays.  Kids are out of school, families may go on vacations, and there will certainly be some cookouts and beverages.   We will circle back to these traditions in a moment.

For many of readers of this column, it also the day to remember those that died in service to our Country.   Let’s remember one person  who was an IT Leader, empowered and trusted by the Business, that you may not have heard about—Major General Harold Greene.

I met him when he was still Colonel Greene, and he was in charge of re-inventing a big part of the Army’s command systems that were related to Intelligence.   Let’s imagine the inputs for an “ERP” like system, using pretty low bandwidth devices, and no edge computing capabilities, trying to manage troop movements,  imagery, and communications, and integrating with logistics, health and safety and more, over 20 years ago.

Yeah, it was complicated.

Colonel Greene brought wisdom, humor and optimistic, yet healthy expectations to the design and deployment of these systems.  His combination of engineering acumen  and genuine leadership helped him gain trust with “The Business”, and he developed fair, demanding and genuine relationships with contractors and engineers.  He was, to put it simply, the kind of CIO that we should all be lucky enough to work for or aspire to be.

MG Greene was the highest ranking US serviceperson to die in Afghanistan.  He was married, had two kids, and was serving in Afghanistan, helping with the training and development of the Afghan security forces.  This makes sense, since he cared a lot about education and helping others around him learn.

Brevity being the soul of blogging, it is an excellent day to think about MG Greene, and perhaps find a little inspiration for our work.   Have a cookout, eat a hot dog, and be with your friends and family.  I think MG Greene would approve.

Comments

|In: Industry Commentary|Last Updated:

An RFP is a means to an end. The end is to transform some or all of a business. The usual means is to gather requirements, match them up with software features as promised by the vendor, and choose the software that matches up the best.

Therein lies a Grand-Canyon-sized gap: connecting the dots separating your understanding of what the software should do (requirements) with how you want your organization to run differently (the transformation).

What a traditional RFP will help you do is find a software solution that provides capabilities the business needs to stabilize, optimize, and transform. It’s a partial solution – its results are, that is, necessary but not sufficient.

The challenge that RFPs are trying to solve is to help you and your colleagues gain confidence in a transformational event. To that end my company recognizes five stages of organizational change: Analysis, Organization, Stabilization, Optimization, and, finally, Transformation. The problem is that transformations need to be understood and considered—not sold. You are expecting that the world is going to change in some way, and that the way the business has been working may not work in the future.

Which is a key reason you need to avoid the tiresome “Chocolate or Vanilla?” argument. It’s a transformation. You and your colleagues are re-imagining the business and the marketplace it competes in. Chocolate, vanilla, sprinkles and the rest are about keeping IT costs down – a perspective that can cripple a transformation before it has a chance to start.

Once more, with feeling: If you set your goal as selecting software, even the best choice will be the wrong choice. Your goal is transformation. Your selection goal is choosing the best combination of software and solution partner.

There are a lot of ways to select this combination (the starting point is to include the implementation team) that work better than RFPs. Depending on your situation, here are two simple tools to consider:

One approach is largely suggested by a regular reader (Mike!) is to build a decision score card. This approach is useful when you are still narrowing down options—but maybe not for making a final decision.

  • Form a selection team of key partners in your company that need to have a say in the decision.
  • Ask this team to create a list of 20 high-level requirements, described in terms of business capabilities, not software features and functionality, to verify that the solution provider has a basic grasp of the fundamentals.
  • Ask the vendor to pick 10 or workflows that cover these requirements. Budget a bit of time- this should take a half day at the most. Make sure to budget time for questions and answers—with both the vendor and yourself getting a chance to ask questions of each other.
  • Ask the selection team to score on how well the vendor showed that the solution answers the needs for current as well as future state of the team.
  • Ask the vendor for an informal quote—just on the software licenses. Don’t ask for an implementation quote from them. Also ask for customer references and talk to other customers.
  • Vendors generally are not the best implementors of a system. This seems counterintuitive, but it is often the case. In some SaaS software options, you may not have a choice, but where you can, ask the vendor for introductions to at least three implementation partners. To start, ask yourself only one question—“Can I imagine that this company will work shoulder to shoulder with me?” If you find yourself saying any form of  “Not really”, keep looking.

The next suggestion is the Conference Room Pilot (CRP), described here as “An Agile variant optimized for implementing COTS and SaaS applications.” (See this article for more info  https://issurvivor.com/2015/11/30/devcrpops/ )

This definition captures a lot of the benefits of the approach—In a limited amount of time, you will gain confidence that the system, team and individual, from all sides of the table, can quickly address requirements and productively demonstrate even a bit of limited value quickly. You will leave this event knowing this project is going to work—Or not. You will also know if you feel comfortable knowing if you and the team are ready for this.

The key challenge is having a “CRP” master or mistress of ceremonies that can explain the process, keep everybody on track, and eliminate confusion,  and maintain forward momentum. This person needs to show people how to use the system, describe the adaptations made, and be emotionally available for new users who are giving this their best go. There should be a completion goal each day, and frequent check-ins to make sure that people are staying on track. By definition, this is a form of Agile, and Agile is radically centered on the humans in the process.

Comments