Effective Leadership is Key

Photo courtesy of fit2finish.com

My nephew’s soccer team recently got a new coach and they were playing a pretty tough team. As the kids ran up and down the field, I noticed the differences in the coaches. My nephew’s coach was passive, looking at his phone, talking to his wife and generally not caring what happened in the game. Now, this is a group of 7 to 8 year olds, so they’re not on the Olympic training team. However, the opposing team’s coach was a completely different story. He had a playbook, he walked up and down the field with the kids, he was engaged and cared about the game.

As I watched goal after goal scored by the opposing team, it dawned on me. These kids are so young, but effective leadership is still so important. You could see the look on my nephew’s face as they were losing terribly. His initial enthusiasm waned and he wasn’t trying as hard. The kids on the opposing team were high fiving each other and smiling. It all had to do with their leader. If my nephew’s coach had been an effective leader, they could have won or at least had a fighting chance.

Having an effective leader whether in sports or in an office environment is so important. With an ineffective leader you have ineffective employees. Processes fall by the wayside, things don’t get done, and employees feel let down. A manager’s job is to work with their employees, coaching them, challenging them and praising them. Of course, there are days where all managers feel overhwhelmed and stressed. But, you have to remember that your team is counting on you to lead them through these challenges. Whether your team is a success is up to you. Are you an effective leader or are you looking at your phone like my nephew’s coach, waiting for the end of the game?

Integration: Klingons vs. Elves

Integration is largely dismissed by those interested in purchasing software these days. Quotes like “don’t worry, we’ll make it happen” or “oh, it’ll all come together in the end” are heard in meetings as everyone rushes to sign the vendor’s contracts before the end of the fiscal year. Unfortunately, six months later the same people are saying “the vendors weren’t upfront in their demos with us!” and “I don’t understand what’s so difficult about all this, why can’t they just make it work!”.

If you’ve ever integrated different systems together, you know that integration is where the rubber meets the road so to speak. From a technical perspective, I’m not a fan of bolting two (or more) different systems onto each other and forcing them to talk to one another. However, many times it has to be done and if that’s the case, it needs to be planned accordingly. The best way I can explain an integration effort is this:

System 1, a.k.a. “Worf”: A Klingon who hails from the planet Kronos. Worf has been characterized as a “swarthy humanoid”, doesn’t like cold weather and enjoys a bloody battle. Speaks Klingon.

System 2 a.k.a. “Enel”: An Elf who hails from Valinor in Middle-earth. Wise and immortal, Enel is a skilled hunter and has pledged to preserve the world. Speaks Elvish.

Worf and Enel couldn’t be more different. In fact, they’re completely different in every way imaginable. So, how the heck do you make them talk to one another? Hire an interpreter (i.e. 3rd party software tool) to assist in the language barrier? What similarities does Worf have that Enel can understand (i.e. temporary tables)? What symbol of understanding can be passed between them (i.e. Web Services or APIs)?

To ensure that the Klingons don’t invade the Elven continent of Middle-earth and destroy an ancient civilization, it’s important that you get your Supreme Council in a room (i.e. project stakeholders) along with your Trusted Advisors (i.e. IT architects, etc.) and determine the best way (or ways) for Worf and Enel to communicate with one another before you join their people together as a nation. Otherwise, prepare for Worf’s battle cruiser to enter Middle-earth airspace and it won’t be pretty.

What Happens to Bad Software?

There are a lot of things that happen to bad software. Back in the early 80’s, Atari decided to bury their bad software in the New Mexico desert. Literally, bury it.

It’s not 1983, but bad software still gets buried. It gets buried in a different sense. It gets bought by another vendor and “updated”, it’s “transformed” from a server-side application to a “cloud-based platform”, and lest we forget the “let’s customize the heck out of it until it’s unrecognizable and works better” (or worse in many cases) approach.

If you’ve been in technology for any length of time, you’ve probably worked with bad software. What makes it so bad? The bugs? The worthless GUI? The endless hours of futile user acceptance testing?  To me, it seems that there’s a gradual tipping point for bad software where the project goes from “Wow, let’s buy it” to “Well, let’s see how the requirements and design phases play out” to “did they even unit test this?” to “the end users hate user acceptance testing because the bugs are so bad”.

How can bad software be fixed? Or, can it be fixed at all?  Honestly, bad software is a real challenge.  You’ve got users who are being told by their managers that they have to use it, senior managers who are trying to ensure that they’re not scalped by their CEO / CFO for purchasing bad software, and a technical team managing so many workarounds related to the bad software that there are workarounds to the workaround.

If your project is using the Waterfall software development life cycle approach, the decision to pull or somehow salvage bad software has to be made early.  Don’t attempt optimism in the case of bad software.  If it’s broken and you know it, go back to the vendor and work with them to fix it before you roll it out to your end user population.  Keep in mind that this will probably throw your project into the red and you won’t be the most popular person until you get the project back on track, but it’s worth it. Talk to your stakeholders and explain the situation, because end users shouldn’t be held responsible for unit testing a bad software product.  However, if your project is using an Agile approach, you’re usually in a better place, as the 30 day sprints are more flexible and allow iterative changes to be made to the product.

As project managers, we’re responsible for the entire project, including (unfortunately) bad software. So, come up with a game plan to work with your vendors, stakeholders and project team to ensure that you aren’t rolling out bad software. Your end users will thank you!