Turbulence, IT and The New CIO

Turbulence, IT and the CIO

The New CIO is a weekly article about the challenges facing today’s CIO as well as what can be done to prepare for future challenges.

I just completed reading The Upside of Turbulence: Seizing Opportunity in an Uncertain World. Great book.  Go buy it…the link above is an affiliate link or just go grab one from your favorite bookseller.

The book does an excellent job of discussing the world of business and the role that turbulence has played in shaping it.  Donald Sull does a great job describing how to embrace turbulence and seize the opportunities that turbulence can bring.

How do you embrace turbulence?   By being agile.

Before we continue, don’t confuse ‘being agile’ with the agile development methodology….while they may be similar, for the purposes of this article, I’ll be talking about a different ‘agile’.

That said, let me clear up what I mean when I saw agile (and what Donald Sull means when he uses it): Agile isn’t about speed. Agile has to do with the ability to change course when needed. Being agile means taking a look at your organizational landscape (strategy, operations, etc) and breaking up the long-term view into smaller samples of time to make it easier to see and respond to opportunities.

Dr Sull defines agility as:

“the capacity to identify and capture opportunities more quickly than rivals” (p. 138).

In addition, he uses the concept of air warfare to help tell the story of how agility can provide tremendous benefits.  Out of these stories of air warfare, Dr Sull introduces John Boyd, a military strategist who helped with a lot of the science behind the F-16 and F-18 fighter jets, and Boyd’s OODA Loop.

John Boyd's OODA Loop
John Boyd's OODA Loop (Courtesy of Jeff McNeill's Flickr stream)

What is the OODA loop?  It stands for Observe, Orient, Decide, Act.

What does it have to do with IT? Everything.

In order to be an effective IT group and CIO in the world today, you’ve got to have some flexibility (i.e., be agile) so you can move quickly when opportunities arise.

As we all know, we are being asked to do more with less.  The only way to do that, is to remain flexible (as well as have a good team and not overwork them).  In addition to being agile, you’ve got to have a strategic plan and know how to execute that plan.

By using the OODA model, you might be able to be agile, plan and react as necessary.  Let’s look at how you might incorporate the OODA model into your business life.

Observe

To use the OODA model, the first (and perhaps most important) step is to continuously observe.

Observe your situation.  Look at your organization, team and the competitive landscape.  What can you and your IT team do to help move the company forward?

In addition, observe how your team operates. Do you have enough people?  Do you have the right people?

Is your strategic plan still valid based on these observations? What are the politics of your organization?

Orient

While observing, you’ll need to orient yourself to your landscape.  Orientation (in the OODA model) is all about positioning yourself.

Is your organization changing direction?  Are your competitors doing something differently that previously?  Is your team becoming overloaded?  Do you have the right people on board to make your plans successful?

Decide

You are observing your situation and have oriented yourself to the climate….now all you have to do is decide to do something.  Can you make a decision?  You better be able to.

In a turbulent world, you don’t have time to wait or over-analyze…you’ve got to decide quickly and move on.  In the world of air warfare, if you wait you die and in today’s world your fate and your organization’s fate might just hang on your ability to decide.

Act

You’ve decided on a plan of action.  Now you need to execute it.  If you’ve observed, oriented and made the right decision, you can act with ease…but do you have the right people in place?

Many organizations plan well but very few ACT well.  The ability to act and react after observing & orienting is a major reason that some organizations succeed and others don’t.

The New CIO & The Loop

The OODA model is built with feedback loops.  Each action is fed back to the observation stage to review for tweaks.  I’ve found that most organizations are missing this feedback mechanism…strategic plans are made and ‘rolled out’ without any feedback nor any way to change course quickly.

Dr Sull introduces his own version of the OODA loop…he calls it the ‘agility loop’.  The agility loop has four stages:

  • Make sense of situation
  • Make choices
  • Make it happen
  • Make revisions

I like what Dr Sull has to say about the agility loop…whether you use the OODA loop or Sull’s Agility loop, you’ll be in a position to improve your agility.

To succeed in the future, The New CIO has to remain agile.  Using the OODA loop (or Dr Sull’s agility loop) helps you keep your mindset right.  Remember to observe, orient, decide & act. Then repeat.

Enhanced by Zemanta

Big ideas vs Little ideas

Would you rather have one great big idea or tons of little ideas?

Me?  I’m fond of having a lot of little ideas.

Why?  Little ideas are easier to understand, easier to fund and easier to implement. Little ideas can be brought to life with less effort when compared  to the great big idea.  A bunch of little ideas can add up to much more than one great big idea.

Mark Howell over at Strategy Central blogged about a very insightful post by David Armano titled “Unconventional Marketing” that helped me visualize the big ideas vs little ideas approach.

Armano’s idea of Unconventional Marketing mirrors the idea of agility that I’m fond of.  This unconventional marketing  approach allows for small marketing ‘strategies’ and rapid iterations.    Armano uses a great diagram to describe his ideas where he compares a conventional marketing model with an unconventional.

The conventional marketing model  takes a big strategy and runs it through the process…he calls this the ‘big ideas, big bang launch and big budgets’ approach. The Unconventional marketing model takes a different approach.  Armano dubs this the ‘micro strategy, big insights, rapid iterations’ approach.

I absolutely love the unconventional approach.  With this approach you can make course corrections quickly if your strategy isn’t quite right.  You develop your strategy, jump into the development phase, gather insights into how you are doing and adjust as needed until you reach your goal(s).

Think about big ideas vs little ideas like this:

Your ‘big idea’ is to create world peace.  You start thinking about how to reach this goal.  And you think and think.  You pour your heart and soul into developing a plan for world peace. You talk to people and gather other ‘big ideas’.  You research and document endlessly.  You try to figure out how to get in front of world leaders.  If you’re lucky, your hard work might pay off…perhaps you get in front of some important people.  But will your plan succeed?  Perhaps.

Instead of taking the ‘big idea’ approach, why not start with a few little ideas.  What if your idea was to create a more meaningful and peaceful life for your family and your neighbors?  Why now try and create create peace and tranquility within your neighborhood?  That’s something that can be easily conceptualized…and then you can move further into other neighborhoods.  Eventually your ideas could take root throughout your city. By starting small, you’ve created much more than a ‘plan’…you’ve created something real.  You’ve created something that can be replicated easily by other people.

This approach will allow you to start with small ideas and move on them.  It is usually much easier to come up with a bunch of small ideas than to come up with the “one big idea”….if you wait until you get your “big idea”, you may never start…or finish.

There are many who would argue that BIG ideas are more important and more meaningful.  I disagree.  Of course, a BIG idea that has merit and is achievable is worth noting and is worth pursuing. That said, don’t let the chase for the BIG idea get in the way of achieving the little ideas…these little ideas can deliver outstanding results.

Reblog this post [with Zemanta]

Agility & Business

Michael Hugos had a really good post on CIO.com titled “Agility Means Simple Things Done Well, Not Complex Things Done Fast” that provided the best definition of “agility’ that I’ve found.  He writes:

Experience shows me (again and again) that agility is not about working fast but about finding elegantly simple solutions to business problems. You’ll know you’ve found an elegantly simple solution when the business people agree it solves their most important and immediate problems…

…because people can’t find these simple solutions, they mistakenly claim that agility itself doesn’t work. They come to this conclusion because they attempt to be agile by cramming complex solutions into short development cycles through working harder, longer, and faster…

…An elegantly simple solution (a robust 80% solution) doesn’t do everything (there isn’t time for that), just the most important things.

I found Michael’s article via George Ambler’s The Practice of Leadership Blog (great blog…check it out) in a post with the same title as Michael Hugos’.  In George’s blog post, he says (emphasis mine):

We spend too much time complicating our lives by trying to do too much, too fast! There seems to never be enough time to do something correctly, but always enough time to do it over again! Given to complexity of managing business, we’re prone to think that complex solutions, are better solutions. Instead we need to focus on implementing good enough solutions, solutions that bring about small wins. Small wins, if continually applied, in a thoughtful and strategic manner, quickly add up to significant results. Small wins are more manageable and have less of an impact if they fail. Seeking big wins are extremely difficult, prone to failure and require significant political will! Focus on the small wins…simple things done well… repeatedly provide true competitive advantage.

Hugos and Ambler have some amazing insight in these two passages.

The original intent of Michael Hugos article was to describe Agile development methods but I think it can be easily transferred to any piece of an organization, which is what George Ambler is pointing at in his post.  This is also what I’ve been trying to say in previous posts (see Simplicity equals Success, Is Perfect Worth It? and In Search of Perfection for examples).

Agility isn’t just needed for competitive advantage…it is required for survival.  Organization’s without agility will not survive…so why then do organizations and people still rely on heavy handed processes and bureaucracy?  I think it’s because they don’t know any better.

In order to bring agility into the bureaucratic organizations, a value must be placed on the ability to be agile…hopefully some of the research occurring today and in the near future will help.

How would you show the value of agility to your organization?

Zemanta Pixie

Agile Project Management and Product Strategy – A Case Study

Due to the length of this post, I’ve created a PDF version for those that would like to download it and/or print it out. Click here for the PDF version of Agile Project Management & Product Strategy.

Over lunch recently, a good friend and very experienced project manager shared his thoughts on managing software development projects when he said:

“Software developers are so hard to manage. They never do what I tell them, never report status and are always behind schedule and over budget. Most times, they never finish the project!”

I asked him to think about what he just said and to think about whether he is ‘managing’ the project or ‘leading’ the project (a project manager should be a good leader first and foremost). I then jumped into my philosophy on managing projects using a more agile mindset and finished with the following comment:

Perhaps software developers aren’t any harder to manage than any other function…perhaps it’s the system that has been put in place to manage the developers and their activities that causes the problems.

I believe most software developers are bright and hardworking people…but they tend to be put into situations that drain all of the initiative and drive they may have. Traditional software development methods (e.g., Waterfall, etc) can and have been used quite successfully in software development projects but the large up-front requirements gathering, milestones and end-of-project testing usually result in software that is late and buggy. Of course there are successful projects that have used these traditional methods. The majority of successful projects are those that are given the appropriate level of resources, people and time and give the product development team the ability to get their job done without much hassle. Some smaller organizations have a difficult time with these traditional methods because they aren’t able to fully resource the project and aren’t able to be as flexible and responsive with these methods.

I recently encountered one of these smaller organizations who needed some help crafting a product development plan. As you will see, we were able to change the development plan from one that delivered a revenue generating product in 12 months to one that delivered a product with ~85% of the same features in 6 months at less than half the cost. Oh…and we were able to capture $3.5 million in revenue after 6 months.

Case Study – Software Development

I was approached by a small technology company to see if I would be interested in helping them re-design their product development strategy to release a product within 6 to 9 months in order to beat their competition to market and gain an edge over their competition. The product had to be something that clients found useful, valuable and worth paying money for and needed to be able to compete with the ‘big boys’ that were moving into this space. It appeared to be a pretty daunting task: take a product that was planned for release in 9 to 12 months and have it ready for market in 6 months.

The company is a small startup focused on a niche market in the technology field product uses a third-party content management server package to serve up large amounts of data from the enterprise network. They had some very good developers and had hired a consulting company to develop a product development strategy to provide for a product release to their client base in 9 to 12 months. This same consulting company had been planning on actually doing the development work as well.

After reviewing the plan, the senior leadership team and board of directors felt that 12 months was much too long to wait to enter the market. They had heard rumors that some very big names in the industry were starting to make moves that would allow them to enter this niche market within 12 to 18 months and felt that they needed to be first to market in order to gain a competitive advantage in the marketplace.

I agreed to help with the project and joined the company in a consulting role to help them create a new plan that would see a product released within the next 6 months.

The Original Product Development Plan

On my first day with the company, I walked into the office and found myself staring at a very large Gantt chart hanging on a wall. The chart had the words “Product Development Roadmap” written across the top and looked just like every other Gantt chart ever created (e.g., milestones, resources, dates, timelines, critical path outlines, etc etc). My first thought was that least they understood what they were trying to do and had a plan. My second thought was ‘what are they delivering and when are they delivering it?’

I sat down with the team and over the next few days and discussed the product development strategy. I realized that the original development plan created with zero lead time (each task could only start when the previous task finishes). My gut feeling told me that his was done to lengthen the project and create more billable hours for the previous consulting company.

Since the plan was created using zero lead times, it required that a considerable piece of the network architecture design had to be completed before database design could be completed. In addition, a significant portion of the database design had to finish before any work on the CMS Integration could be started. The User Interface design could begin during Database design and was scheduled to begin after network design in conjunction with CMS integration.

As you can see from the high-level overview of the plan shown in Table 1, it would have taken 9 months before a product was available to demo and/or beta release to a client and 12 months for a final release.

Table 1: Original Development Plan

TaskTimeline
Network Architecture100 Days
Database Design100 days
Content Management System Integration160 days
User Interface120 days
Demo to Clients9 months from start of project
Documentation30 days
Testing30 days
Total11 to 12 months from start of project

After reviewing the plan and talking with the leadership of the company, I started looking at methods to “bring the plan in” so we could provide a demo and beta release much sooner than 9 to 12 months out.

The original resource schedule for the development provided for 1 network architect, 1 database architect, 1 content management expert, 1 user interface ‘guru’, a documentation specialist and 2 QA specialists.

The New Product Development Plan

To create the new development plan, I visited a few key clients to gather requirements for features that they felt must be in the software in order for it to be valuable to them. After these visits, I sat down with the development team and created a “Top Feature List” to help us focus the development efforts on only those features that were the most valuable to our clients.

Interestingly enough, the items that ended up being the most important items for the clients were the last things to be implemented in the original development plan. It’s amazing what a little bit of client communication will do!

Using agile software development methods, common sense and the “Top Feature List” gathered from my discussions with clients, the team and I created a development plan. The new plan would allow for the most important (i.e., valuable) features that our key clients were looking for to be ready for release as a Beta release within 3 months.

Due to the small team size and the inability to bring in additional developers, some of the tasks still needed to be performed in serial but most of the tasks were performed in parallel with each other. Table 2 shows the new product development plan.

Table 2: New Development Plan

Start Iteration 1
TaskTimeline
Database Design – DBA Resource30 days
Network Architecture – Network Resource45 days
User Interface – GUI Resource45 days
CMS Integration – DBA Resource15 days
Total Time45 days
Demo to Clients1.5 months from start of project
Start Iteration 2
TaskTimeline
User Interface – GUI Resource45 days
Documentation – Document Resource15 days
CMS Integration – DBA Resource45 days
System Testing- QA Resource30 days
Total Time45 days
Beta Released to clients3 months from start of project
Start Iteration 3
TaskTimeline
Network Architecture – Network Resource45 days
User Interface – GUI Resource30 days
CMS Integration – CMS Resource15 days
System Testing – QA Resource15 days
Total45 days
Beta2 Released to clients4.5 months from start of project
Start Iteration 4
TaskTimeline
Network Architecture – Network Resource30 days
User Interface – GUI Resource15 days
CMS Integration – DBA Resource30 days
Documentation – Document Resource15 days
System Testing – QA Resource45 days
Total45 days
Final Release to clients6 months from start of project

The budget for the new plan turned out to be less than half of the original budget, although we weren’t trying to dramatically cut costs, the shortening of the development cycle by half brought us considerable cost savings.

The outcome of the plan thrilled senior executives, investors and clients. Based on the first Beta release, we were able to book about $1.5 million in revenue that may never have been booked if we had used the original plan. The initial Beta release was nothing like the final release from the original plan, but it did provide the key features that the client(s) wanted to see.

The release after the final iteration contained about 85% of the features from the original plan. Think about that…85% of the product features in half the time at less than half the cost! That’s the power of agile thinking!

After the final iteration, the product was released to quite a bit of fanfare. In addition to the revenue we had already gained with the Beta release, we were able capture another $2 million in revenue from new clients and create a great footing for the company in the marketplace. At the time that version 1.0 was released, the competition was still mired in product planning and development and their release dates seemed to be at least another 12 months out.

Conclusion

After releasing version 1.0 and capturing $3.5 million in revenue, the company was able to attract quite a bit of interest from investors and potential buyers. They ended up being gobbled up by a much larger competitor for quite a bit of money (many times multiple earnings). I’d like to say it was all my doing…but it wasn’t…I just helped them to see a new way of looking at the development process.

Using agile methods allowed us to deliver real value to our clients and to our company by create a product in half the time. We were able to deliver $3.5 million in revenue because we focused on the needs of our clients and delivered those features that they thought were the most valuable.

That is what Agile Project Management is all about. Delivering value to clients.


Note to readers:
When I use the word ‘agile’, I don’t want to imply that I am explicitly talking about iterative or agile software development methods such as eXtreme Programming (XP), Scrum, Feature Driven Development (FDD) or other types of ‘Agile’ methods. Agile methods like XP and Scrum are the framework for my project management methods for managing software development projects but I am not a strict proponent of any one method or process over another. By using the word agile, I am trying to capture the frame of mind that someone should have to be able to accurately focus and respond to clients’ needs in today’s competitive world.

 

Reblog this post [with Zemanta]