Project Management

Taking the Plunge

In case you actually read this description, the beginning of the blog is about preparing for the PMP exam. It then evolved into maintaining my credential. After taking a break for a few years, I'm back and will be blogging about project management, in general, and probably a bit of agile on a regular basis.

About this Blog


Recent Posts

What's in Your Project Management Tool Belt?

Scale Your Product Owners

When is a Good Idea a Bad Idea?

Is it a Project or Maintenance?

Do You Deliver Product or Value?

Innovation and Onions

Innovation and project management go hand in hand.  If you're innovating, you probably have at least one project on the burner. So, why is innovating so much harder than project management?

The easy answer is that, usually, project management is a highly structured, well documented process, whereas there does not seem to be a magic formula for successful innovation.  A project has a point at which it is done, by definition. Innovation evolves. Scrum-based flavors of Agile seem like strong candidates to use for a project management framework for innovation, but will it still look that way when you peel the onion and see what's hiding inside?

I know, the onion analogy is old, but it is appropriate, although slightly flawed. What makes it appropriate is that there is more to innovation than what you see on the surface. Each layer may be similar to the one before it, but without the underlying layers, there's not much to it.

I'm seeing a parallel between Agile and onions, now.  Please, make it stop!

My point is that, like the outer layer of an onion, an innovation effort does not stand alone.  There is a core of culture, people, processes, tools, and data that all affect a company's ability to innovate.

I'm going to borrow a concept from Agile to describe a common challenge to innovation: technical debt.  In Agile, technical debt refers to old or poorly written code that needs to be refactored in order to deliver a desired feature.  From the perspective of innovation, I am using this concept to represent systems, software, and processes that need to be changed before an innovation can be successful.  If you ignore this technical debt, you risk failure, and we're not talking about a software release, any more.

If not addressed properly, technical debt can become part of a painful cycle.  With software used in multiple markets around the globe as an example, let's say it's been several years since the last major upgrade.  The required downtime wasn't feasible because of global sales events, which is how your company earns revenue.  Your company has reached the point where the software cannot reasonably support the changes you want to make.  You either need to perform the upgrade, or implement new software.  Either way, there will be downtime. It takes close to a year, but you make the change and start innovating, only to realize that you've started the cycle over again and 5 years later you have to make the same decision; upgrade or replace your software.

The flaw in the onion analogy is that innovation is not occurring on the outside of the onion.  The growth of an onion occurs in its core, forcing the outer layers to stretch and grow.

If you're expecting me to compare the core and outer layer of an onion to IT and the Business, prepare to be disappointed.  This mindset is a factor in why some innovation efforts struggle. IT provides the business with functionality; the Business provides IT with purpose.  It should be a symbiotic relationship, where both stretch and grow together, but it is often hampered by those that view it as a parasitic relationship, both in IT and the Business.

Once upon a time, I was an IT project manager at a claims processing center. The Business was frustrated with the service not provided by IT, even though the real problem was due to software that the business forced upon IT. IT, feeling like it was performing miracles just keeping the software running, expressed that the Business could not function without IT. One day, the software crashed. Hard.  After a couple of days with no real progress, the Business began processing claims by hand.  It was much slower than normal, but they made it clear they could function without IT.

And with this adversarial relationship, it took significant time, effort, and money (to replace the software and fix relationships) before innovation could begin again.

Back to my original question, "Why is innovating so much harder than project management?"  Because it's not just one thing.  Innovation is many things happening at once.  Good project management can help an innovation effort be successful, but unlike an onion, if you're only looking at the surface, you really have no idea what else is going on.  All parties need to realize that business and technical innovation go hand in hand.  If you try and accomplish one without the other, you're missing the big picture.

Posted on: December 08, 2016 12:14 AM | Permalink | Comments (7)

Even if you're on the right track, you'll get run over if you just sit there.

- Will Rogers