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.
Few events start a project manager's day off worse than a yellow sticky note on his or her monitor saying, "The finance manager would like to talk to you." An email is equally as bad; however, the note at your desk means that someone actually hunted you down looking to talk about, you guessed it, finances. There must be some problem. Everyone knows the finance folks would never wander into project-land to invite you out for a friendly cup of coffee. You quickly review the project's finances. Everything seems in order. With a sigh, you contemplate whether you should walk over and see her or will a phone call be the least painful option? Yes, painful. Anytime the finance manager calls, there is going to be a lot of new work.
Leadership is more than leading the people reporting to you. Too often, you need to lead people over which you lack any authority. The absence of hierarchical advantage adds a challenge, but is ideal training on how to deal with managers, customers, and difficult people. The key is making them feel the direction chosen is theirs. One of the best methods of doing this is storytelling.
Vision, honesty, and transparency: three key traits of an organization that can guarantee project success. This was summed up in last week's interview with Tom Cox, the host of Blog Talk Radio's Tom on Leadership program. His audience, primarily from the C-Suite, is keen to understand how troubled projects are a reflection of their organization's overall health. Projects are, after all, the proverbial canaries in our organization's coalmine. Projects stop performing because there is trouble in the organization.
"I just want to be a project manager. I don't want all that responsibility." The room was silent, save a few exasperated sighs. We all looked around trying to figure out how we would handle the comment. However, there are many levels of project management maturity and only the highest levels require leadership. In fact, the prominent certification process—PMI's PMP®—has little to do with leadership. So where do we learn about leadership and how can we improve our leadership skills?
Management comes up with great plans for sweeping change, it implements the plans, and three years later the organization has reverted to the way it was before the initiative. Changing to new breakthrough systems is hard; maintaining those processes and procedure is far more difficult. The reason progressive ideas can have a successful implementation only to have the organization regress to its prior state a few years later has its roots in societal practices and human nature.