By

3 Comments

Cementing a formal work initiation process for IT projects

I’ve written before on how the most important thing that a CTO/CIO deals with is the proper allocation of resources. I’ve discussed how doing proper resource allocation isn’t just a matter of deciding exactly what Sam or Mary will work on this week, but actually figuring out the whole project portfolio, including sustainment activity, and determining the general picture of what portion of resources will be dedicated to each chunk. That project portfolio management concept is a meta-level above, and arguably more important to focus on than, the nuts-and-bolts action of allocating the time and tasks for individuals.

Here’s another critical meta-layer to the overall issue of how to properly allocate resources: how is work spawned, initiated, defined, before it goes through the various approval steps involved in portfolio management? Where does the work stem from, and how does it enter the stream? Who decides that the suggested project is worth pursuing at all? Does simply anyone’s suggestion count as a way to spawn work? Lots of organizations don’t have a very clear path for this. The result is that lots of stuff ends up getting worked on informally, and resources get overcommitted and stretched, and both quality and timely delivery suffer greatly.

I’ve found over the years that it’s best to have a single, formalized conduit: yes, a dreaded form, collecting basic initial information about the intended project or need, and capturing important facts and assumptions about the approach, cost, sponsorship, and likely return on investment.

[Read more…]

Filed Under: Pillars of Purview, Process
By

4 Comments

Why the CIO should air the dirty laundry

Trust. It’s important. And a company typically instills a huge amount of trust in its IT department, particularly (as is often the case today) if that IT department is responsible for the operation of systems (such as web sites) that contribute significantly to the bottom line.

I’ve been at the helm of several IT departments that operated the product of the company: social networking or other web sites. And that’s when I learned how vital it is to “air the dirty laundry” internally throughout the company about the stability of the key systems. Too often, I have seen IT staffs that were reluctant to announce that the system was down, in the hopes that it wouldn’t be such a big deal if they could only get it fixed quickly. Of course, often a quick fix wasn’t in the cards, and users started to a) notice the outage; and b) wonder if anyone in IT was even aware of it.

My response to this is to insist on the airing of dirty laundry. Less euphemistically: timely, comprehensive, broad-audience notification of all system outages and impairments. Specifically, emphasize the following:

[Read more…]

Filed Under: Communication, Pillars of Purview, Process
By

1 Comment

Software development’s classic mistakes and the role of the CTO/CIO

Here’s a post of a type I rarely do: a reaction to an item recently posted to the Internet. Specifically, a day or two ago, Steve McConnell’s firm Construx, Inc. released their update of McConnell’s list of classic software development mistakes. This survey and its results is worth everyone’s time to read (and ponder) carefully. Their summary of the paper is as follows:

“Classic mistakes are ineffective software development practices that have been chosen so often, by so many projects, with such predictable results that they deserve to be called classic mistakes. Steve McConnell first introduced this concept in Rapid Development in 1996. Construx recently updated McConnell’s original list of classic mistakes and then conducted a survey to assess the prevalence and impact of these mistakes. This white paper shares survey results–both expected and surprising–and analyzes the survey findings.”

The Construx survey results document pretty much speaks for itself, and provides interesting detail that I won’t repeat here. Hence, this is a bit of a “piling on” kind of post, in part because I respect McConnell’s work in the extreme, but also because I want to add some “color” to what he intentionally presents with (relatively speaking) a “just the findings” deadpan dryness.
[Read more…]

Filed Under: Pillars of Purview, Process, Role definition
By

1 Comment

Budgeting maintenance and support for IT

What does IT do, anyway?

Well, among other things, IT spends money. In many modern companies, the expenditures made through IT are among the highest in the company, second only to salaries and marketing.

What does that mean? It often means that when cost-cutting time comes around (as it tends to do, in cycles, at most companies), there’s a particularly harsh spotlight that shines on IT expenditures, and a vast amount of pressure emerges to reduce these, quickly.

Unfortunately, the “quickly” part of that last sentence just isn’t realistic. A lot of IT expenditures can’t be turned off (or down) at a moment’s notice. In many or even most cases, the company has already signed (and paid for) maintenance agreements with hardware and software providers that typically last a year, if not longer.

[Read more…]

Filed Under: Financial, Pillars of Purview, Process
By

1 Comment

Rock and a hard place: why estimating turns into a squeeze play

I wasn’t ever a very good bridge player, and it’s been decades since I played. Hence, using this analogy may be stretching matters, but as is typical, I took away some key metaphors from my time with the game. One is the squeeze play, where you force your opponent to discard a vital card. It’s similar in a way to what’s called Zugzwang in chess, which describes a situation where one player is put at a disadvantage because he has to make a move, and by doing so (any move, in other words) will force himself into a weaker position.

How does all this relate to CTOs and CIOs? Consider the case of having to estimate how long a specific project will take, particularly early on, usually before any kind of detailed requirements are even remotely fathomed. Note that this kind of estimating is among the most critical activities that you and your organization will do, because it feeds into the organization’s whole prioritization and costing process as a whole. Unfortunately, it gets you into exactly this kind of squeeze situation. If you say a project is going to take what’s considered to be “too long”, you’ll get beaten down about why you can’t do it faster. If you blithely “sign up” for doing it too fast (say, as fast as they want it), there’s a huge risk that you won’t be able to deliver.

[Read more…]

Filed Under: Estimating, Pillars of Purview, Process
By

Leave a Comment

A team-oriented approach to making good hires

I made two really bad hiring decisions in a row a few years back, and I have to admit that it shook me for a while. I won’t go into details about why these two hires were horrendous (although I should note that the problem was not because the requisite technical skills were lacking), but the most important thing I can say about them is that both hires happened when, with all good intentions, I departed from the general hiring process and practice that I’ve evolved to over the years.

This process doesn’t always work out exactly as described below, for scheduling reasons, but here’s what I strive for and what I’ve found tends to get great results:

[Read more…]

Filed Under: People, Pillars of Purview, Process
By

7 Comments

tanstaafl: An Introduction to IT Portfolio Management

I’ve already written about how the most important task of management is the proper allocation of resources.

By that, I don’t just mean figuring out that Joe and Bob need to work on Project X this week. At a higher, macro level, the issue of resource assignment deals with how the company, as a whole, plans and spawns its suite of projects.

Much of what I’ll have to say in this post will perhaps seem to be intuitive, even obvious. Yet once again, for all its obviousness, it has been astonishingly controversial at many companies. Better said, these concepts seem to be intellectually understood and accepted, yet then resisted, perhaps due to the old adage of “everyone wants to get into heaven, but no one wants to do what it’ll take to get there.”

What does it take to get there, then? You need to plan and schedule projects holistically, not one by one. This approach is commonly known as Project Portfolio Management (PPM), although that term often is used more to describe the aspect of selecting and prioritizing IT Projects based upon corporate strategic and tactical objectives, and then optimizing the whole set to ensure maximum utility. All of that is both valid and critical, of course. I’ll have more to say about project selection criteria later, and in the meantime would point you to some of the references contained in my Lagniappe section.

[Read more…]

Filed Under: Pillars of Purview, Process
Mastodon