Back in the eighties, I was working for a large aerospace company cutting my teeth as a systems analyst. My bosses were a little older then I am now, and they loved talking about the days before cubicles, pontificating on how personal computers were inferior to mainframes, and reminiscing about the days of the BOMARC missile. It was their way of telling us thirty-something kids that they were in control and we needed to respect their position. Then, as now, information was king and these pterodactyls were not letting it go. To earn the stripes, one had to partake in the tribal rituals, smoke cigars over three-martini lunches, and attend your boss's parties. They saw no value in email let alone the boondoggle shop floor automation project I was part of. In two words, communication sucked.
A friend of mine alerted me to an article in a PMI Community post titled Is Manipulation Ethical? From the title, I thought this would be neat read. However, the article was pretty swallow. How foolish to think that a 650-word article would address an issue that has plagued philosophers for a few millennia. The initial reaction was to the manipulative title, which was deceptive. It led me to believe the article would supply some profound knowledge. The short treatise failed. To its credit, though, it made me think. On the second pass, I decided that I disliked the article. In fact, its thesis—manipulation is ethical—is morally wrong.
Decisions, deshmisions, what is the big deal? Anyone can make a decision! Hardly. After years of working with ineffective initiatives and consternated companies, I have a healthy respect for the D-word. It is all about the seven 'tudes—ineptitude, attitude, fortitude, altitude, aptitude, incertitude, and vicissitude. Some organizations obtrude the 'tude in which they are imbued, while others are denude of a common 'tude.
I have written about, spoke on, and lobbied against blame. Regardless, it just seems like a bottomless pit of contention, conversation, and criticism. People fail to see how to correct a crisis without hastily pointing fingers at failure's first sight. Yet, in the next breath they claim accusations serve no purpose as they attempt to sidestep the fate of blame's gauntlet. We can talk about how we should solve the issues rather than going on the proverbial witch-hunt to find the individual, group, or organization who we think should be burned at the stake and wear the corporate tattoo of failure. Why do we need this and what does it achieve?
People routinely ask me the question, "What do you do when you find yourself on a project that is a hopeless failure?" It was raised again a few weeks ago in a Focus.com roundtable and then last week in an interview with Andy Kaufman. It only matters if the executives above the project are ignorant to how dire the situation is. It is tricky, trying to convince someone that they have a problem when they refuse to acknowledge the obvious—a tough and politically dangerous sell. The general consensus is "dust of the résumé." However, there is a logical approach to the problem—be logical.
Last week I gave a presentation at the San Diego PMI Chapter's Tutorials conference. Flanking both sides of my ten o'clock presentation in the leadership track was Steve Romero. His two presentations were on IT governance. His energy, insight, enthusiasm, and passion (not to mention being the IT governance evangelist for CA Technologies) made him an excellent selection. And, what is so news worthy about that? Nothing. However, for someone that has little regard for adding one more layer of management to solve a problem, I was surprised that I sat through both of his presentations. He provided a three hours of information on governance—both PMOs and PPMs—crammed into two intense and valuable hours.
Information Technology organizations continually struggle to build systems that meet their customer's needs. They work tirelessly developing solutions that are delivered late, difficult to use, or deficient in key features and functions. This is nothing specific to the last couple decades; it stretches back to the first systems developed. Fredrick Brookes eloquently underscores this in his recount of the 1960's software engineering project to develop the IBM 360 in his book The Mythical Man-Month (1975) and is required reading for all IT executives. For the Chief Information Officer to solve this problem takes a new approach, one, nearly opposite from today's direction.
Few would question that executives are responsible for ensuring projects are aligned with the corporate strategy. They also need to ensure these initiatives remain in line with these goals as business conditions change. To achieve this, they have to be engaged with the project when it starts and maintain that context throughout its life cycle. This requires more than ensuring the project maintains its scope, schedule, and budget; projects must deliver value. Too many projects start with the inspirational support of upper management, but as the project (or company) drifts, the executives have long since disengaged from the project and are unable to straighten out the misalignment. This wastes company resources and hinders the company's ability to deliver.
Businesses exist to make money. To improve operations they create various initiatives with promises of improving the bottom line. Projects, though, cost money. They do not make a profit. The dichotomy in a strapped economy to spend savings on projects to improve future profits usually results in the conservation of cash. Many an argument has been had over whether it is better to run improvement projects, burning precious cash and heading off the competition, or taking the traditional approach and wait for times with better cash flow. Subsequent to 2008's financial folly, it is well known that most companies sat on their reserves and waited. That action may have some unintended consequences that are in the midst of surfacing.
Months ago, maybe over a year, now, I was blasted for talking about innovation in the context of information technology (IT) projects. The gist of the complaint was that all IT folks think they are building some new groundbreaking, revolutionary application that requires the latest in technology's tools. I agreed with his argument, qualifying that although this seems to be a pervasive theme, IT is a discipline that needs to keep one-foot in the pioneering frontier. Regardless, I had to concede that many innovative initiatives are more about a technician playing with some new toy. Jobs like implementing ERP interfaces to manufacturing execution systems (MES) only sound new. Unfortunately, I must say, "been there done that." Most IT is neither new of innovative. To avoid squandering funds, executives must understand and direct what needs to be innovative and permeate the company's culture with that knowledge. Otherwise, the wasted time and expense will suck a company dry.