All Posts in Organizational Design

|In: Industry Commentary|Last Updated:

Surely the stupidest of all the commentary about Healthcare.gov is the oft-repeated, “The Obama administration can’t even put up a website.”

Or maybe it’s ignorant, not stupid, because calling it “a website” is a lot like calling the Curiosity Mars rover “a car.” Also, the website part — the user interface — generally receives compliments from those who have looked at it closely. Of all the criticisms of Healthcare.gov, this is probably the only one that is completely wrong.

Healthcare.gov is IT in the headlines … irresistible to Recognized Industry Pundits (RIPs) like yours truly. But instead of participating in this version of “dog pile on the rabbit,” here are some thoughts you might be able to actually use.

Start here: There’s a scale hierarchy when it comes to programming efforts. Ignoring enhancements — efforts one programmer can handle in a month or less — the smallest are projects, which require a team, multiple tasks, and a plan.

For some organizations, that’s it. Enhancements and projects. But smart ones recognize that projects fail, and they fail in non-linear proportion to their size. Once you get beyond about seven core team members and about six months, failure rates skyrocket.

That’s why smart organizations “chunk” larger efforts into multi-project initiatives, and chunk behemoth efforts into multi-initiative programs. Whatever else happens, the individual projects will at least complete, delivering their planned work products as they do.

“Chunking” also helps prevent phase compression. As mentioned last week, there’s a tradition in project milestone management: If an early phase goes long, it’s always because the additional time and effort will allow later phases to be shorter.

That’s the rationalization. The way it actually works is that if the early phase went long, the whole effort is probably bigger than it looked at first. But as saying so is political suicide, the project team assumes subsequent phases will be shorter instead.

With every late milestone, though, the time compression between remaining milestones increases until there’s almost no time left for the final two phases, which are, of course, testing and training.

But if instead of phases you have separate projects, phase compression is less likely. The project manager probably won’t even be responsible for the subsequent projects. Even if he or she is, the subsequent projects haven’t been planned yet. When they are, their project managers have at least a fighting chance of developing reasonable timelines for them.

Sounds like a panacea, doesn’t it? It might sound like one, but it isn’t one. By separating what used to be phases into separate projects, you gain in reliable delivery, but you risk losing coherence. This happens with initiatives complex enough to have multiple concurrent projects going on, and happens in spades with multi-initiative programs.

Among the many coherence problems large programs face, three that stand out are (see this week’s ManagementSpeak for the translation):

First project wins: Large programs that include large-scale software development require standardization on several fronts, from user-interface style through matters of architecture and software engineering. If individual project teams make these decisions on demand, each will be optimized for the project that made it, not for the program as a whole.

Large programs need someone to be responsible for applying the whole-program perspective to these decisions.

Scheduling: This is pretty basic. Projects compete for resources. Not just staff (if it’s just staff, say so — don’t call people “resources”) but minor things like test environments and business department time and attention for whatever you need their time and attention for. Also, some projects depend on the results of other projects from time to time; if the other projects are late, their delays can ripple through the whole program.

With one big project, all tasks are plotted on a single schedule, so interdependencies can be made explicit, letting the project manager at least manage the chaos, even if there’s no way to prevent it.

But with multiple concurrent projects, a whole different kind of coordination is required so projects don’t run into each other, because there are more different kinds of inter-project dependency than just finish-to-start and its brethren.

Silo-ization: What, you thought large programs were different from any other large organization? They’re just as prone to devolving into rival siloes, based perhaps on which initiative you’re part of, or whether you’re process or tech, or whatever. Preventing silo formation in programs is the same as anywhere else, too: You foster a global sense of identity, and define a collaborative culture.

And, of course, privately “coach” the guilty.

Comments

|In: Career Management|Last Updated:

Well this was painful, and it’s relevant to how CIOs can thrive in the PC-plus era.

Office 2013 stopped working on my Windows 8 tablet – every Office application crashed immediately after being launched.

Neither of Office’s two repair processes helped. Un- and re-installing Office didn’t help. Reverting to the last breakpoint didn’t help either. The Windows 8 refresh process did, but required that I reinstall Office. Which then refused to activate.

According to the first Microsoft tech I worked with, Microsoft limits how many times Office can be reinstalled on the computer for which it is licensed — a restriction not mentioned in the EULA. Anyway, for a mere hundred fifty bucks he was willing to sell me an extended warranty, after which he would fix my problem. I asked to speak to his manager and he refused. Not a good showing.

The next day a different tech grasped that this was a licensing server problem, not an Office problem, and quickly fixed it.

Let’s imagine a CEO accepts the now-popular suggestion that cloud computing and BYOD mean it’s time to move IT into the business departments, which will all happily replace the company’s expensive and complicated enterprise applications with cloud-based SaaS alternatives.

So they do, cheerfully buying their PCs from Costco and their copies of Office through Amazon, while using Dropbox or Google Drive for shared storage. (Contrary to popular wisdom, by the way, they won’t move off of Office, because they can’t. The alternatives just can’t handle what the company’s more sophisticated employees need; also, many of them exchange documents, spreadsheets, and presentations with vendors and customers who need to see them in unscrambled form.)

This arrangement works just fine. Until, that is, something breaks, like for example, Office starts to crash for no apparent reason. Only now there’s no help desk to call, because IT has been divvied up among the business departments, and, by the way, the company no longer has an enterprise license because who’s going to take care of buying one?

Answer: While decommissioning IT, most likely everyone would have figured out the need for some IT, to handle things like the company’s networks, PC provisioning and end-user support.

Which is how CIOs can survive the current round of why-IT-doesn’t-matter-anymore thinking: Embrace it.

Start with the IT service catalog. While some of its proponents took the catalog metaphor off a cliff (yes, that was intentional), suggesting it include such niceties as pricing, the core idea … that what IT does should be public knowledge … is a pretty good idea, and, by the way, the more political the management culture, the better this idea is.

So here’s what you do. As part of the next IT strategic planning cycle, gather the company’s executives together and make the following speechlet:

We all know about the cloud. You all probably know that “bring your own device” is a reality, and that we in IT are now asked to support a lot of employee-owned technology. You might have read some of the forecasts that say IT spending outside of IT will and should be growing a lot faster than IT spending inside of IT.

The cloud and BYOD are real, they’re important, and they mean we need to re-think how we make IT happen in this company. We all know spending is a bad place to start. It’s an output variable, not an input variable. So here’s what I propose.

As an executive team, our job is to establish the principles we should use for deciding what should happen where. With these principles to work with, my team will wade through the IT service catalog and figure out how our new principles change how we as a company make each service happen. We’ll bring the items that change the most back to this committee for review.

Once we’ve figured out who’s going to do what, we can figure out what this means to the budget … and whether we should be moving staff, too.

Yes, this will be uncomfortable. It isn’t the first time new technologies have re-drawn the business/IT boundary, though. The electronic spreadsheet, for example, moved most small-scale development out of IT, just as VOIP moved the telephone system into it. All in all you’re better off leading this parade than you are trying to stop it from happening.

And as a fringe benefit, it gives you an opportunity to remind the company’s top executives of all those things IT does that nobody seems to appreciate.

It’s all good. Or at least, it’s better than any of your other alternatives.

Comments