All Posts in Project Management

|In: Metrics|Last Updated:

“Could you please stop saying there’s no such thing as an IT project?” a reader politely asked. “When I have switches/routers/servers that are out of support from their vendors and need to be replaced with no business changes I have to call these IT projects.”

I get this a lot, and understand why folks on the IT infrastructure side of things might find the phrase irritating.

And I agree that projects related to IT infrastructure, properly executed, result in no visible business change.

But (you did know “but” was hanging in the air, didn’t you?) … but, these projects actually do result in significant business change.

It’s risk prevention. These projects reduce the likelihood of bad things happening to the business — bad things like not being able to license and run software that’s essential to operating the business; to purchase and use hardware that’s compatible with strategic applications, and so on.

It’s important for business executives to recognize this category of business change project, if for no other reason that none of us want a recurrence of what happened to IT’s reputation following our successful prevention of Y2K fiascoes. Remember? Everyone outside IT decided nothing important or interesting had happened, and that’s if they didn’t conclude we were just making the whole thing up.

Successful prevention is, we discovered, indistinguishable from the absence of risk. So we need to put a spotlight on the business risks we’re preventing so everyone recognizes our successes when we have them.

Not to mention the need for everyone to be willing to fund them.

Which leads to a quick segue to IT architecture, which, depending on the exact framework and source, divides the IT stack into information systems architecture, subdivided into applications and data; and technology architecture, subdivided into platforms, infrastructure, and facilities.

Switches and routers, along with everything else related to networking are infrastructure. With the exception of performance engineering, infrastructure changes ought to be invisible to everyone other than the IT infrastructure team responsible for their care and feeding.

Servers, though, belong to the platform sub-layer, along with operating systems, virtualization technology, development environments, database management systems … all of the stuff needed to build, integrate, and run the applications that are so highly visible to the rest of the business.

The teams responsible for platform updates know from painful experience that while in theory layered architectures insulate business users from platform changes, in fact it often turns out that:

  • Code written for one version of a development environment won’t run in the new version.
  • The vendors of licensed COTS applications haven’t finished adapting their software to make it compatible with the latest OS or DBMS version.
  • Especially in the case of cloud migrations, which frequently lead to platform, infrastructure, and facilities changes, performance engineering becomes a major challenge. And as everyone who has ever worked in IT infrastructure management knows, poor application performance is terribly, terribly visible to the business.

Et cetera.

Not that these platform update challenges are always problems. They can also be opportunities, for clearing out the applications underbrush. Part of the protocol for platform updates is making sure all application “owners” (really, stewards) aren’t just informed of the change but are actively involved in the regression testing and remediation needed to make sure the platform change doesn’t break anything.

The opportunity: If nobody as the steward for a particular application, retiring it shouldn’t be a problem.

On a related topic, regular readers will recall the only IT infrastructure metric that matters is the Invisibility Index. Its logic: Nobody notices the IT infrastructure unless and until something goes wrong.

Invisibility = success. Being noticed = failure.

Something else regular readers will recognize is that Total Cost of Ownership (TCO) is a dreadful metric, violating at least three of the 7 C’s of good metrics. TCO isn’t consistent, complete, or on a continuum: It doesn’t always go one way when things improve and the other when they deteriorate; it measures costs but not benefits; and it has no defined scale, so there’s no way to determine whether a given product’s TCO is good or bad.

But perhaps we should introduce a related metric. Call it TCI — the Total Cost of Invisibility. It’s how much of its operating budget a business needs to devote so those responsible for the IT infrastructure can continue to keep it invisible.

They’ll keep it invisible by running what aren’t IT projects. But are quite technical nonetheless.

Comments

|In: Organizational Effectiveness|Last Updated:

More and more, services organizations of all kinds are relying on what we used to call telecommuters and now refer to as “remote employees.”

I’ve written about the subject before, concentrating on how to make telecommuting work, both for the organization and for its telecommuters. If you’re interested you’ll find the columns here.)

What I didn’t cover in any of them: How services firms, and especially large services firms that extensively rely on a remote workforce, collect them into project “teams,” put them in front of customers for the project kick-off event, maybe take the new “team” to dinner at a nice restaurant, and expect the “team” to function as a team.

I enclosed team in scare quotes because members are left to interact on a basis of trust and alignment to a shared purpose with no basis for either.

What’s truly scary is how few services firms take any steps at all to turn their assemblage of remote employees who have never before met into a functioning team.

What’s only a smidgeon less scary is how often large corporations mimic this services firm worst practice. It’s less scary only because the poor teamwork that results is more visible in internal teams than with those fielded by a vendor.

As is so often the case, the problem begins with the difference between tangible and intangible costs and benefits.

If you aren’t familiar with the terms and what makes them problematic, we covered this ground a month or so ago, in “KonMari and your business.” How it applies here: Bringing remote team members together results in easily recognized expenses: airfare, hotel bills, and meals. They’re tangible costs.

The benefits, in contrast, are intangible: Getting team members together helps them understand who each other are as human beings; it gives them a chance to reconcile hidden assumptions, work styles, perspectives, and particular strengths.

It lets project managers communicate nuances and subtleties about the project’s goals and priorities far beyond what they can accomplish with teleconferences, email, and even web conferences accompanied by PowerPoint.

As a correspondent once put it, email communicates facts, but it doesn’t build teams. Teleconferencing and web conferencing permit the exchange of ideas, but not the connection of co-workers.

I say the benefits of bringing team members face to face are intangible because failing to do so constitutes a risk — something bad that might happen in an uncertain future. Worse, it’s the kind of risk that, even when it turns into reality, still won’t be acknowledged as the cause of the problems in question.

For example, every good project manager recognizes the critical role rapport with the project’s sponsor and governance committee plays every time something unexpected comes up. Project managers can build rapport in direct proportion to the time they spend face to face with these fine folks, and especially the time they spend face to face early in the project, before issues arise.

Second example: Agilistas … practitioners of real Agile methodologies, not “Scrummerfall” variants that replace Agile’s “individuals and relationships over processes and tools” with the exact, polar opposite … recognize the importance of being able to consult, frequently and informally, with product owners, subject matter experts, and end-user representatives throughout development of whatever is being developed.

Unless team members have met these people face to face at least once, the social hurdles that must be overcome to have even one conversation are considerable. Frequent and informal conversations? Good luck with that.

Which is why offshore agile projects rely heavily on on-site business analysts to have these conversations. And that’s okay. It isn’t great, but it’s okay, so long as the business analysts and project team members have had the opportunity to interact face to face.

In the interest of not beating the subject to death and of providing useful solutions, I trust the useful solution is, by now, obvious: If, as a vendor, you’re planning to deploy teams of remote employees, bring them together at the beginning. Specifically, bring them together for a week of orientation and socialization a week before the official project kick-off meeting.

Follow that with three weeks of working together on-site in a bull-pen environment. During this period, schedule as many briefings as possible — sessions in which various project stakeholders explain the current situation and their hopes, concerns, and expectations for the project’s outcomes.

Couple this with a professional-grade, on-demand web conferencing environment. It will be essential for collaboration once the team has been built.

For building the team? Not so much.

Comments