Prevent project diversions or delays

thCAC18C6H.jpgAbout six and a half hours into a nine-hour flight to Frankfurt, Germany, my plane was almost diverted to help a gentleman who passed out three times before the flight attendants even showed up. This is the scene of my story. The characters include one good Samaritan, a doctor who was flying home and two slow-moving but well-meaning flight attendants. This mid-flight drama gave the rest of us passengers an opportunity to practice one of the oldest form of social media—gossip.

 

It’s strange that you can sit next to a person for six hours and not even know their name, and this is considered protocol these days. Yet, a single abnormal event will reduce or remove inhibitions (what I sometimes call the stranger danger adults tend to have on mass transit). In this particular case the doctor was able to stabilize his patient and the other passengers (either that or the pilot turned on the sleeping gas). At this point there was enough passenger hot air, that the buoyancy of the plane could have been called into question.

 

Removing "grapevine" communications from the software development process?

 

You are probably asking yourself what this story has to do an IT expert blog. I’m glad to hear that I’m not the only one asking myself that question. The truth is that it has a lot to do with how IT groups communicate internally during the software development lifecycle. This story is closer to the truth than most of us would like to think. Think of the project manager as a commercial airline pilot; his first responsibility (despite popular belief) is to the airlines and then the passengers.

 

Project managers in a lot of cases make judgment calls based on disjointed communications—similar to grapevine gossip— whether to divert plans or shoot for the original goals of the project. In most cases whether big or small, I would say the choices that are being made have less than a 50 percent chance of being the right one.

 

 

I have a theory that I’d like to share with you on why I believe this happens:

 

  1. The first being what I sometimes call “The hot potato effect” of an iterative or lean environment. This is when an item (requirement, code, or documentation) has been mislabeled or miscommunicated from one group to another during handoff. The lack of process and/or documentation on something as simple as a vague requirement, can divert the whole project by the testing stage.
  2. Disjointed processes and tools give credence to the old saying “You are making a mountain out of a mole hill”. Each group in the development lifecycle process is no longer limited in their communication and reporting. They no longer simply use only the tool that best fits their needs they also use their own forms of reporting and communications. In a lot of cases this can be as simple as instant messengers and XL reports. The problem is that these extra forms of communication complicate the tracking process
  3. Siloed teams across applications and chosen professions, has led to an adversarial or competitive environment. If your company is considering suspending teambuilding outings because of injuries sustained at the last picnic, you may fall into this category. Without proper teamwork in place, teammates quickly become enemies. (With this in mind, the next team-building event could have a jousting contest…)
  4. With a distributed resource model, the sun literally never sets on any given project. In theory, this sounds like a project managers dream come true. In reality, this model has inherent flaws that complicate even the smallest of issues. These issues range from language, cultural, or philosophical; but the biggest obstacle is simply time. Here’s an example, I write a requirement in Chicago and develop in Mumbai. It can take days to solve simple problems through normal communications channels. Add methodology such as Agile on top of that, and you find a scrum master who never sleeps.

 

thCAIU1N0Y.jpgI could continue for at least five more points, but I believe you get the jest of the issues facing the IT software development lifecycle process and project managers. Originally, the project manager only had to land the proverbial plane safely. But in today’s IT high-paced environment, the manager is required to land on time as well.

 

 

 

But you say you want Autopilot? I have an answer for you!

 

If you’d like to put your project on autopilot, I believe you need three key parts to build your navigation system:

  1.  One of the first requirements is traceable and timely communications that are visible to the project. Looking at my example of the developer in Mumbai. Let’s say he has a question about a requirement, you automatically lose 12 hours of development time because of the time difference.  You also have the possibility of even longer delays if it involves one or more key resources. This is why I’m a firm believer in a centralized visible repository with built-in communications capability and traceability. This should also include some type of customized escalation process. It is inevitable with outsourcing that communications are lost.
  2. A central point of integration and accessibility with a wide range of preferred tools of the trade is essential for successful takeoff and landing of any development project. All of the systems in a jet are integrated so where pilot has enough information to make the best choices for the airline and passengers. I’d like you to think on a question, “What do IDE, Microsoft Word, Excel, application modeling tool, SourceSafe, and a myriad of other preferred IT tools have in common?” I’d like to come back to this question later.
  3. I would recommend breaking down communications to its simplest form; which in logical terms is mathematics. In our industry, it’s often referred to as key performance indicators (KPI), which when developed correctly, can allow the project to avoid the biggest of storms—even when autopilot is turned on. KPIs can range from a simple scorecard to a complex gap analysis, but both boil down to the same thing.  If you don’t have a central repository and process, everything has to be done manually or not at all. KPI’s act as your forward-looking radar, they allow you to avoid storms.

 

I guess it’s time for me to serve the in-flight meal, I’m sure that it’s better than what I got on my flight.  After flying the friendly skies especially over the last couple years, I have realized that getting the right information to the right people in the shortest amount of time is the only way to guarantee your destination. If the pilot doesn’t have the correct coordinates, you end up in Wichita. If the passengers don’t have the correct gate, they never get off the ground.

 

You are probably wondering which tool I prefer when flying the friendly skies of application development. That’s a simple question to answer.  I believe there’s only one tool that can meet all the criteria needed no matter the size of project your piloting—Application Lifecycle Management (ALM). It provides all the essentials to build an aerodynamic environment while still allowing your airlines to customize the interior to fit their process.

 

Finding the right tool in the box

 

If you’re  still wondering “what IDE, Microsoft Word, Excel, application modeling tool, SourceSafe, and a myriad of other preferred IT tools have in common?” They all can integrate into ALM, giving your IT crew the capability to use the best tool for the job.

 

Take a look at your current project; I’d like to know how many forms of communication your project uses to get the job done. You can also look at it this way, if anyone in the flight crew didn’t show up for a week--would it cause your project massive delays or cancellations?

 

We never really heard what happened to the gentleman, (sometimes gossip is unreliable). Our flight continued on to Frankfurt, and about 30 minutes before landing the young man returned to his seat. In fact, he looked  really healthy and refreshed walking back to his seat. The ultimate lesson is: in-flight oxygen works wonders when crossing the Atlantic.  

 

Frankfort.gif

 

Thanks

Wh4tsup_Doc

 

thCAV376UU.jpg

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Michael Deady is a Pr. Consultant & Solution Architect for HP Professional Service and HP's ALM Evangelist for IT Experts Community. He spec...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation