All Posts in Project Management

|In: Organizational Effectiveness|Last Updated:

When you move your family, even if it’s into your (and presumably their) dream home, the inconveniences outweigh everything you love about the new place.

At least they do for a while, which is why, if you’re in the change business, you should read and re-read William and Susan Bridges’ Managing Transitions. It clarifies the essential divide separating a change’s immediate annoyances (the transition) from its ongoing joys.

Which is why I had my annual physical before upgrading our household to Microsoft 365.

I wanted my blood pressure to look good.

So while I like my terabyte of cloud storage and 50 more gigs for email, I didn’t at all appreciate the three multi-hour chat support sessions required to make them available (don’t ask).

Not to mention the time spent finding all the features that have been rearranged.

Which brings us to why, if you’re in the change business, you should also ponder how and why it is that plug-in hybrids and pure-play electric vehicles are more likely to dominate future driving than the vastly superior alternative — cars powered by hydrogen fuel cells.

Disagree? Explain why in the Comments. For our purposes today just go with it.

The problem with hydrogen powered vehicles when compared to plug-in hybrids or pure-play electrics is as easy to grasp as it is difficult to solve.

Pure-play electric vehicles need electricity. As a nation we have an electrical grid that delivers it. It might (and does) require upgrading, but it’s there. Plug-in hybrids need the grid, along with gasoline or some other hydrocarbon-based fuel. We have a deep and rich system in place for obtaining, refining, distributing, and selling this stuff in massive quantities.

Hydrogen? Even overcoming the unfair perception, created by the Hindenberg, that hydrogen is too explosive to ever be safe. I’ve read that most of those who died were killed by the fall; the hydrogen itself, being lighter than air, floated up as it burned).

Where was I?

Overcoming the complete absence of a hydrogen distribution network will most likely prevent hydrogen from ever catching on as a fuel.

Now about that software project you’re running.

By now, assembling requirements or their Agile user-story equivalents, is something most IT shops know how to do. Your developers know what outputs the software is supposed to deliver, and the inputs and algorithms it needs to deliver it.

Your testers have the same knowledge and know how to turn it into an organized, and ideally automated test plan and program. Your project might not deliver bug-free code, but its bug count won’t be the sort of embarrassingly huge number generally reserved for astrophysicists trying to describe the age of the universe in months. No worries on that front.

You’ve ticked all of the check boxes put in front of you by the Change Advisory Board (CAB) and Architecture Review Board (ARB). These i’s have been dotted and t’s crossed.

And you’ve involved Organizational Change Management (OCM) throughout. They’ve communicated with everyone to explain why the change is necessary and good, and they’ve put a training plan in place which you’re ready to launch just as soon as you know the official deployment date.

What could go wrong?

Welcome to the problem of hydrogen logistics. Sorta. It’s an analogy. Don’t worry if it’s not a perfect fit.

Anyway, imagine, for the sake of argument, the software your team is preparing to deploy is to consolidate the 17 supply chain management systems that are the legacy of past corporate acquisitions.

You might have designed the new software to be flexible enough that all 17 supply chain managers can use it to manage their supply chains as they like (the car will run on hydrogen, gasoline, diesel fuel, or batteries) at which point you might as well have designed and developed 17 separate supply chain management systems. You’ll deliver all pain and no gain.

Or else, all 17 supply chain managers agree to standardize their processes so they can use the same software the same way. It’s as if enough gas stations start selling hydrogen, fuel delivery trucks are retrofitted to transport it, and so on that anyone driving a hydrogen vehicle anywhere can fill it up before it runs out of fuel.

Let’s hope process standardization is the plan. If it is, make sure your OCM trainers avoid a common mistake: Teaching business users how to operate the software, not how to do their jobs a new way with the software.

That leaves you with one advantage over hydrogen: You don’t have to convert supply chain management all at once.

But you do need to figure out who will go first.

And last.

# # #

Want to be more adroit at making change happen in your organization? Get yourself a copy of There’s No Such Thing as an IT Project. It’s nothing but practical ideas you can put to use tomorrow.

Assuming, of course, you’re a fast reader.

Comments

|In: App Dev Methodologies|Last Updated:

“Oh, yes, we’re using Agile,” my client’s two CIOs told me.

Their company had engaged us to assess their IT practices and effectiveness. In addition to consolidating to one CIO (some recommendations are easier to figure out than others), we also suggested IT should adopt Agile to guide its application development efforts.

Their situation wasn’t all that unusual. The road to Agile is replete with forks. Travelers should avoid many of their tines.

My client had chosen a popular one: They were practicing, not Agile, but Haphazard.

Sadly, they ignored our 12-step App Dev recovery program, the two CIOs presided over a calamity, and eventually our former client became a division of a larger non-client.

Astonishingly, many business and IT leaders continue to misunderstand Agile, and that doesn’t include last week’s advice about applying Agile thinking to business situations beyond application development.

In some cases the misunderstanding is willful, grounded in distrust that Agile’s open-endedness can lead to useful results. If you share this distrust, a question: When you were a child, did you draw up a roadmap for your growth and development that would take you, step-by-step, through your adolescence, remaining education, personal relationships, offspring, careers, retirement, and demise?

Please say you didn’t. I recall, as a teaching assistant back in my grad school days, talking with pre-meds who discovered, in their junior or senior years, that they really didn’t want to become physicians after all, but felt trapped by the choices they’d already made.

I’ll leave the analogy there for you to explore at your leisure. Here, for your edification and amusement, are some other popular misunderstandings about Agile:

Agile isn’t Haphazard: With Haphazard development, project team members wake up each day figuring out what they should do to move the project forward. Or, nearly as bad, the project manager wakes up trying to figure this out.

No matter which Agile variant you use, the project is built around an organized list of Things the Application Should Do — the Backlog.

Agile testing isn’t haphazard, either: With Agile, testing is, if anything, more planned than with its Waterfall alternatives: Those developing a chunk of functionality — usually a module defined by a User Story — know when testing should start on their work. Even more important, every module includes, as part of its definition, a test plan.

Agile isn’t Scrum: It’s a squares and rectangles thing. All Scrum is Agile; not all Agile is Scrum.

Scrum, the most structured Agile variant, is especially popular among IT folk who, schooled in Waterfall development, need control structures and formal governance. There are, however, worthy alternatives.

Especially, look at Kanban, in which developers, when they finish work on a User Story, pull another one out of the Backlog, usually the one (1) with the highest priority, that (2) they’re qualified to develop. Alternatively the project manager assign a user story to them instead.

And, especially if you’re implementing a COTS (commercial, off-the-shelf) software solution, look at “Conference Room Pilot” (CRP) or its close relative, Acceptance Test Driven Development (ATDD). They’re good choices for packages because they’re built around business users trying to do their jobs using the package.

They try, that is, with a real-life business transaction. Wherever they can’t process it, they tell the developers locked in the conference room with them what the problem is. The developers, using the configuration tools built into the package, adjust it to make the problem go away. Rinse and repeat.

Agile disrespects architecture: Developers don’t just write code however they’d like. They develop in conformance to a well-defined application architecture — probably a microservices architecture, but what matters is that, early in the project, the team will, collaborating with the Architecture Review Board or equivalent, establish architectural standards to guide development.

Nor do developers modify the data model whenever they face a situation that calls for it. The project’s consulting data designer reviews the suggested data model change with the developer and, once the two have converged on the best approach, makes the changes happen.

An equivalent set of conversations happens with any other developer solutions that don’t fit the company’s architectural standards.

What doesn’t happen is the developer filling out a form to request a change, for review by some governance committee or other.

That would be decidedly not-agile, as a key Agile principle is that individuals and interactions are more important than processes and tools.

It would also, by the way, ignore a key KJR principle: That there is no process so glacial that it can’t be slowed even further by involving a committee.

Comments