Birthing An IT System

Managing IT projects is no easy task.

You’ve got to get the requirements right. 

Technical issues need to be resolved. 

Dependencies have to be lined up. 

Integrations need to work. 

Design should be user-friendly and intuitive. 

Change management takes real leadership. 

And so much more. 

A lot needs to go right for the project to be a success. 

While of course, just one or two bad apples in the project equation can quickly make for a failure if not controlled for. 

But you can’t let it…the show must go on, progress is waiting to be made, and the systems need to be delivered for the benefit of the organization. 

This is where real strength and determination by so many good people come in. 

Keep moving things forward–one step at a time–don’t stop!!!—another step and another–heave ho, heave, ho–until one day soon a beautiful and efficient IT system is born. 😉

(Source Photo: Andy Blumenthal)

Project Management – The Best Day

So a colleague said something interesting to me about project management:

The best day of project management is usually the first day, but I want to show you that the best day is really the last day of the project.

And as I thought about this, I sort of starting laughing to myself and thinking, you know what, I think this guy has something here. 

– Day 1 of a project, everyone is usually all bright-eyed and bushy-tailed. 

We’re embarking on an adventure together to build something new for the organization and our customers. 

We’re going to team up and everyone will contribute.

And out of the project sausage maker–poof!–like magic comes a new system or product. 

– But as we all know, things don’t always go so smoothly.

With some projects, the pretty smiley faces of day 1 may quickly turn to ugly frown faces.

There is analysis paralysis, scope creep, conflicting or changing priorities, resource issues, technical challenges, or the sausage just doesn’t come our right–oh sh*t!

Thus, many  projects end up going bust in terms of cost, schedule, or performance. 

That is, they end up costing too much, being delivered behind schedule, or just not meeting the performance requirements. 

You have some projects that never even truly get off the ground, have multiple resets, or get dumbed-down or even cancelled altogether along the way. 

So by the time you reach the last day of the project, many people seem like they’ve been through the project ringer. 

I’m sure that I’ve heard more than one project manager say:

Just take me out back and shoot me!

So when this colleague said that he wants the best day of the project to be the last–in terms of satisfaction with the project (not that that pain was finally over!)–I really appreciated this as an awesome goal. 

We should all look to the last day of our projects as the best–one where we can look back and say: 

Wow, great job everyone!  We really got something great done here–and we did it right!  😉

(Source Photo: Andy Blumenthal)

You Can’t Eat The Elephant

So there is a popular saying:

“You can’t eat the elephant in one bite.”

The idea is that you need to break things down in little pieces to get them down. 

If you try to eat the elephant in one bite, I assume that your mouth would easily split in half and your face would literally explode. 

Similarly with projects, if you try to get to the nirvana end state in one fell swoop , the project explodes with complexity and risk, and you will fail miserably.

Thus, managing requirements and phasing them in chunks is critical to projects’ succeeding. 

Sure, customers want to get the Promised Land immediately–where the projects have all the “bells and whistles”–but you don’t want to sacrifice getting the train on the tracks for the accouterments either. 

Think big, but act small–little by little, one step at a time, you can actually eat an elephant. 😉

(Source Photo: Andy Blumenthal)

Say YES!

Really liked this sign on my colleague’s desk.

It says:

Start With Yes

I remember an old boss who used to say:

Don’t make me get through no to get to yes. 

The idea as another colleague put it is to:

Keep a smile on your face and your focus on the customer; everything else takes care of itself. 

Basically, it’s all our jobs to make sure that the customer’s needs are being met. 

That doesn’t mean that we don’t need to differentiate between requirements and desirements or that we need to deliver the yacht in the first go around.

As a 4th colleague put it:

The customer is in the water. They want the yacht. But I can give them a boat. It gets them to where they want to go, and they no longer need to swim. We can work our way up to a yacht.

Good analogy analogy and good things to keep in mind for customer service excellence! 😉

(Source Photo: Andy Blumenthal)

Snowflakes Are Unique

Thought this was an interesting analogy. 

A colleague refers to some customers as snowflakes.

At first, I didn’t get it. 

Then I understood. 

Every snowflake is unique. 

Based on how the ice crystals fall to the ground through different temperatures, moisture levels, and atmospheric pressures, the shape of every snowflake is different. 

Sometimes when it comes to project management, customers too think they are unique, different, and special.

They think that solutions that work industry- or enterprise-wide could never work for them and their wholly distinct ways of doing business. 

Hence, as I learned, the term snowflake. 

For those of us who have been around the project management block a few times, we know that while there are specific customer requirements, most of them are not all that unique. 

And when some customers simply don’t want to do things differently than they’ve done it before, there can be greater resistance to change. 

Hence, the “We’re special. We’re different” reframe along with the standoffishness, doubting, circling the wagons, throwing up obstacles, or just refusing to fully participate. 

Obviously, it’s a lot more difficult to modernize and transform through technology and business process re-engineering when your customers aren’t on board. 

So it is critical to manage organizational change, address the questions, the fears, and elements that are truly unique, and bring the people along as true partners. 

Not every requirement is a snowflake and neither is every customer, but we have to manage the similarities and differences in every project and make sure it improves performance and meets the needs of the customer and the organization. 😉

(Source Photo: Andy Blumenthal)

Agile Doesn’t Mean Endless

So Agile development is great for iteratively working closely with customers to develop and refine information systems that are useful to them and the organization.

But even in Agile, there is a beginning and an end to the sprint planning and project management.

Taking Agile to somehow mean endless in terms of adding more and more requirements or scope creep is not what is intended. 

Agile has to be bound by common sense somewhere between what is needed for a minimally viable product (MVP) and what is achievable with the designated resources, objective, and scope. 

Good project managers always have to be sound arbiters and be willing to ask the tough questions and determine if something is truly a requirement or simply a wish list item that is out of scope (but of course, could perhaps make it in for future enhancements).

We need to understand the difference between genuine customer service and irrational project exuberance based on inflated expectations. 

It’s not a dangerous project bubble we want to create that can and will get busted, but rather a successful project that is delivered for our customers that help them do their jobs better, faster, and cheaper.  😉

(Source Photo: Andy Blumenthal)

Who You Calling Ugly Baby?

So in multiple organizations, I have heard systems referred to as ugly babies!

Whether or not it’s true, it certainly doesn’t make the IT folks that develop, run, and support that system feel very good. 

Are some of these (legacy) systems ugly?

Well, of course, they are. 

Many of them work despite themselves. 

What I mean by that is they are awkward to navigate and use. 

The functionality is flawed or outdated.

The workflows are unnecessarily complex.

The user interface is inconsistent and sloppy. 

The user experience is punishing. 

I told someone recently in using a particular system that was so convoluted:

“Is this system what they give to prisoners and make them use over and over again to punish them for hideous violent crimes?”

Seriously, that’s how it felt, even as I knew it was still lightyears ahead of what a paper process still used in other organizations looks like.

Generally better than the waterfall methodology for the systems development life cycle, I understand that one dilemma with agile development is that requirements can be spotty from sprint to sprint and instead of doing the hard work and thinking it out upfront, users are made to expect a nearly endless series of enhancements and tinkering, which isn’t practical functionally or financially either.

Even an ugly baby is still ours, and we love it and nurture it, and even help it change for the better–that’s part of our responsibility. 

Whether we parented a real baby or an IT system, we have pride of ownership and a sense of accountability to the person, system, and future. 

My father always taught me never to throw out dirty water until you have clean water. 

Similarly, we shouldn’t throw out the (ugly) baby with the bathwater. 

We need to work together–technologists and system users–to make truly functional systems and a user experience more like gaming where the players are so happy, attached (and even addicted) to it that they sometimes don’t even get up to eat or go to the bathroom. 

We should love what we have and use, and we should, therefore, work hard to make these things great.

And an ugly baby can be made gorgeous again. 😉

(Source Photo: Andy Blumenthal)

You Changing My What

So change agents are some of the most sought after…yet most abhorrent individuals on this planet. 

We all recognize that things can be better, and on one hand, we want someone to come and help us make it so…a change agent!

However, change is painful and frequently results in unintended and unwanted consequences, and so on the other hand, we hate change agents. 

Many change agents may not just change things that need to get changed and fixed, but they may change a lot of things that were working just fine before, thank you.  

Can anyone say reorganization? 

Moreover, change agents may not be changing things for the right reasons like the good of the organization.

Instead they may be self promoters, control freaks who have to do things their way, or they may be serial job hunters–next stop change everything and get the heck out of Dodge!

Change agents may work with people to get requirements, input, and vet the issues and the solutions or they may just be paying lip service to others, only to really shove their or someone else’s agenda down your throats. 

You see there is healthy change that is based on genuine learning, growth, and maturity, and then there is change that is destructive, diabolical, and selfish. 

When you decide to change something, what’s your motivation and your goal–is it to right the wrongs in the organization, reengineer business processes, and introduce new technologies or is it to change for change’s sake alone. 

Yes, we did something. Check the box. Tell the management committee. We earned our keep and oh yeah, then some. We changed something, anything. Hip Hip Hooray. Bonus time!

So either you’ll get an award and promotion or you’ll get asked accusingly and threateningly, “Who told you to change that?!”

Change which has no real support or merit is dead on arrival (DOA), and will be gone, gone, gone long after the change agent is gone.

So don’t freak out–the b.s. changes are either going to kill the organization or simply end up in Fresh Kills landfill.

The real changes may actually make you stronger. 😉

(Source Photo: Andy Blumenthal)

Requirements Management 101

This was a funny Dilbert on Requirements Management. 

In IT, we all know that getting requirements can be like pulling teeth. 

No one either has time or desire to provide them or perhaps they simply don’t know what they’re really after.

Knowing what you want is a lot harder than just telling someone to automate what I got because it isn’t working for me anymore!

In the comic, Dilbert shows the frustration and tension between technology providers and customers in trying to figure out what the new software should do. 

Technology Person: “Tell me what you want to accomplish.”

Business Customer: “Tell me what the software can do.”

In the end, the customer in exasperation just asks the IT person “Can you design [the software] to tell you my requirements?”

And hence, the age old dilemma of the chicken and egg–which came first with technology, the requirements or the capability–and can’t you just provide it!

(Source Comic: Dilbert By Scott Adams)

Stack Theory Doesn’t Stack Up

Christopher Mims’ article in the Wall Street Journal today on why big companies get disrupted by others doesn’t make a lot of sense to me. 

He discusses the “Stack Fallacy” of Anshu Sharma a venture capitalist that it “is the mistaken belief that it is trivial to build the layers above yours.”

Mims explains that the stack is like a “layer cake of technology”–where one layer is built on another.

Similar to the OSI technology model where there are architecture layers for physical, data, network, application and so on. 

Basically, Mims explains that tech companies can only invent at a single layer of technology (or below). 

But when companies try to invent up the stack, they fail.

Here’s why…

Mims says that companies despite their size and resources can’t innovate up the stack because they don’t understand the users there. 

But this doesn’t stack up to me. 

Companies can and do use their resources to study and understand what users want up the food chain and what they can’t easily build, they can acquire. 

Apple successfully went from a iPod and iTunes music player and song store to producing a highly sophisticated and integrated iPhone and Apps store where music is just an afterthought.

Similarly, IBM went from being primarily a mainframe and desktop company to being a top-tier consulting firm with expertise in cloud, mobile, social, artificial intelligence, and analytics computing. 

But it isn’t easy for a company to change. 

And to me, it’s not because they can’t understand what users want and need. 

Rather, it is because of something we’ve all heard of called specialization. 

Like human beings, even extraordinary ones, companies are specialized and good at what they are good at, but they aren’t good at everything. 

A great example of this was when NBA superstar, Michael Jordan, tried to take his basketball talents and apply it to baseball…he was “bobbling easy flies and swatting at bad pitches” in the minor leagues. 

As even kindergarteners are taught that “Everyone is good at something, but no one is good at everything.”

Companies have a specific culture, a specific niche, a specific specialization and expertise.

And to go beyond that is very, very difficult…as IBM learned, it requires nothing less than a transformation of epic proportions. 

So I think Mims is wrong that companies can’t undertstand what users want in areas up the innovation stack, but rather it’s a monumental change management challenge for companies that are specialized in one thing and not another. 

Welcome to the world of Apple after Steve Jobs and his iPhone and to the the recent 25% decline in their stock price with investors and customers anxiously waiting for the possible but not certain next move up the technology stack. 😉

(Source Photo: Andy Blumenthal)