Tuesday, April 15, 2014

Reboot Redoux


It’s been almost five years since Lisa Jasper and I wrote Reboot. And it’s (gulp!) time for a second edition of the book. We are incredibly gratified that it has done so well.

We’ve also learned some things. When we originally wrote the book, we based our “4 Things” model on our experience over the years working with CIOs and other tech executives, but we hadn’t really put the model into practice. However, over the last five years, we’ve used our model at dozens of clients to help them improve the performance of their organizations. And it works.

Now, five years later. We’ve got case studies and real world examples of the “4 Things” in action. And, we’ve learned something new as well.

We originally drew our "4 Things" model like this:


But, as we’ve worked through hard problems with our clients, we’ve discovered that the key to making significant improvements is aligning these 4 components. We now call it the “4 Things and the 6 Alignments.”



Alignment of these components is challenging, but the effects of misalignment are clear:



The most recent Standish Group report says that in 2012 (2013 results have not yet been released), 61% of technology projects failed to perform up to expectations (they were not successful). And, 54% of small “Agile” type projects (using modern languages, methods and tools and with less than $1 million in labor content) from 2003 to 2012 failed to perform. While agile delivery methods are certainly an improvement, they are not sufficient because they do not address the other three components of the "4 Things" model. They cannot change the performance of the overall portfolio because the reason the portfolio under performs is the other three components: Strategy, Technology and Organization.

Consider a concrete example: One of our clients ran a large project using a relatively modern delivery model. They were doing delivery processes pretty well: small iterations, frequent feedback, pull processes for demand management, etc. The project failed. Badly.

The project failed, in this case, because this modern delivery model was not aligned to the strategy of the organization. This particular technology organization serves external customers, which can only be consulted once or twice a year due to some unique conditions of their industry. And, the product they were building targeted those customers. And yet, their delivery model had not been adapted to gather requirements twice a year. In fact, as old fashioned as this sounds, this team would have had a greater chance of success with an approach closer to waterfall.

It’s an important lesson. We have to see our technology organizations as a comprehensive system that will produce results. Our model, the "4 Things and the 6 Alignments", helps us, and our clients, root out problems before they inhibit the performance of the portfolio. In the coming months, as we work on our 2nd edition of our book, we will explore some of these ideas in more detail.


Monday, April 14, 2014

KANBAN to death

Consultants often see business trends early because they tend to work in different companies and different industries. Recently, my company has started to see the rise of KANBAN as a trend in technology development organizations. And so far, we aren’t impressed.

KANBAN is borrowed from Lean manufacturing practices. Its focus is on improving the productivity of individual resources by ensuring there is always a pick list of work to “pull” down and work on. It sounds good in theory. And, it may even work on improving individual productivity on development teams. However, building software is not the same as building cars or taking chocolate off a conveyor belt:


As I mentioned in my last blog post on "Why do technology projects fail?" building software isn’t as simple as just executing a bunch of simple tasks.

Because users expect a well-designed solution, and because these expectations are rising, processes that focus primarily on the efficiency of the team or its individuals instead of on the quality and design of the product are likely to steer most organizations in the wrong direction. And in fact, this is what we are seeing.

In the last 6 months, we’ve seen 3 projects based on KANBAN fail. In each case, the team felt good about their progress. They liked the method. They liked the tools that supported it. And they all failed. They failed to deliver on a reasonable schedule and they failed to deliver software that people wanted to use. But, I’m sure they did it efficiently.

Technology guys: KANBAN at your own risk.


Tuesday, April 8, 2014

Why do technology projects fail?


Thought Ensemble recently had its annual company trip.  One of our Thought Topics (read more about Thought Topics in a previous blog post by Lisa Jasper here) was why technology projects fail so often.  It’s an old topic, probably as old as technology projects themselves and there has been much discussion about it; a google search will turns up hundreds of results.  But, I found one result in particular to be very interesting: The Standish Group’s report on the success rates of Agile vs. Waterfall projects.











At first blush, this looks like significant progress (and that is exactly how the Standish Group reads it.) However, a closer read of the data shows that 58% of technology projects even using agile still fail or are challenged. That’s not particularly impressive (and that's an understatement).

At Thought Ensemble, we’ve spent a lot of time thinking about this problem. Our focus is on the strategic use of technology, but strategy is only useful if you can implement it. Because of this, we’ve recently built our Technology Product Delivery Framework™ and piloted it with a few of our customers.




I won’t go into the whole thing here, but there are two key features that distinguish it from a traditional agile process.

1. Design: Agile projects tend to drift due to a fear of upfront design. However, design of software has become increasingly important. Expectations for good looking, well designed, easy to use software are rising. The traditional agile processes focus on small incremental improvements, which does not solve this problem. For example, one of our clients recently had a “challenged” project that followed the agile mantra fairly closely. They delivered the product, but customers disliked it even though it had all of the functionality they needed. It was ugly and hard to use. Design matters.

2. Challenge: Agile projects often have the idea of an iteration review or sprint review. This is a helpful first step, but our experience shows that this isn’t a sufficient amount of challenge for most projects. There simply isn’t enough scrutiny of what is being designed and built. Because our process enforces and structures challenge sessions throughout the life of an idea, projects are substantially more likely to be successful.



Monday, February 24, 2014

The outsourced flexibility illusion

























The single most common reason we hear for outsourcing particular roles in corporate IT organizations is staffing flexibility. In other words, someday, when we have to remove some people, we’d rather remove the contractors than our own staff. Usually, the IT department blames this strategy on the finance department. The argument goes something like this, “We’d like to keep X% of our staff as contractors, so that if we hit a future snag in our growth, we can easily remove the contractors and keep the staff.”

I haven’t seen any concrete statistics on what percentage of staff in most IT organizations are outsourced; anecdotal evidence would seem to indicate between 30% and 60%. We’ve seen organizations as high as 80%.

Of course, outsourcing this heavily comes at a cost. First, there is a literal cost. We pay a premium to contractors. But, there are also significant soft costs: loss of intellectual property, lack of contractor dedication to company vision, reliance on staff who can leave easily, etc.

But, these are not the most significant problems with outsourcing for flexibility. The most significant problem is that this process in fact makes the organization LESS flexible. Let me explain what we’ve seen over and over again.

When a company encounters a need to reduce its staff, it is usually because of some kind of market or company financial trouble. The company needs to move quickly to reduce its costs. And, invariably, it seeks the quickest path to that cost reduction. First, it turns to its contracts with its outsourced vendors. But, here is where the problem begins, unlike its relationship to its employees, it has contracts with its vendors. Contracts have start and end dates, and chances are, the end dates don’t meet the company’s needs. Of course, frequently, they buy their way out of these contracts or cancel with some notice, but most often, they follow the path of least resistance: the relationship with employees of the company is far more flexible. They can be severed at will. And, they are.

And, of course, this exacerbates the problem. Perhaps the company was 40% outsourced before the layoffs, now they may be 50% outsourced AND now because there is a higher reliance on more expensive labor, the organization is actually more expensive for the output it produces.

If it is truly finance departments that require this kind of outsourcing, why doesn’t anyone tell them they are crazy?



Thursday, February 20, 2014

Caught in the Target fiasco




I recently got caught up in the Target data breach fiasco and was issued a new credit card. And, of course, then had to go through all the various companies that have my card on file and update them. There was a remarkable difference in the process at the various institutions... and, one company that stood out with a well designed solution to the problem.

Most of the companies I had to change the card with basically required me to execute the world’s worst typing test. I was making these changes from my phone while on the road which required me to type 16 random digits perfectly while only seeing one digit at a time (they mask each digit after you type it.) It was incredibly painful and the iPhone’s auto-correct feature doesn’t work particularly well for credit card numbers.

But, Uber was different.

Uber gave me the option of taking a picture of my credit card. A simple picture and it had all of my data. No typing test. No pain. I don’t know why Uber was able to have such a solution when no one else did, but my guess is that they consider their product to be at least as much the technology solution as it is the cars they move you around in. In other words, because they see technology as strategic (especially mobile technology) they spend time designing excellent solutions for it.

Thursday, September 5, 2013

Reading a book




 Recently, I unfortunately left my iPad at a friend's house.  And, while waiting for it to be shipped back to me, I decided to (gasp) read an old fashioned book . . . the kind made out of a dead tree.  At first, it was nice.  Like coming home after a long trip or sliding a foot into a well worn shoe.  It was nice to turn the paper back and forth.  It was even fun to dog ear a page.

But then, I tried to read before bedtime.  I know this may sound crazy, but my little paper book requires an external light source.  I have to turn on a light beside the bed . . . and damn that thing is bright.  It spreads light all over the room and it’s hard to fall asleep when bathed in light from a giant bulb.  But, I made it.

Then, the next day, I ran across a word I didn't know, and again this may be hard to believe, but there is no dictionary in my paper book.  And, of course, I didn't bother to look it up.  I still don't know what it means.  A paper book is less educational than an electronic one.

I can't wait to get my iPad back.


Thursday, June 6, 2013

What we're reading and writing









                               The Secret to Putting Together an Insanely Successful Team
                               When Content Eats Marketing
                               The Time is Right for an "IT Petting Zoo"
                               SAIC Weaves Tech Into the Business Fabric
                               IT Departments Won't Exist in 5 Years








                               A Game of Phones