CIO Perspective – Managing Complex Projects – Defining the Problem

Probably the most important lesson I learned early in my career concerning the management of complex projects was the need to have a clear understanding of the core problem that was to be addressed. It’s amazing to me how many IT projects fail because management lacks an understanding the problem to be solved or the opportunity to be exploited.

Back in early 1974 the Penn Central Transportation Company which was formed by the merger of the New York Central and Pennsylvania Railroads went bankrupt. The trustees who had been appointed by the bankruptcy court were approach by Victor Palmieri, who was then CEO of the railroad’s non-rail subsidiaries including Arvida Corporation, Buckeye Pipeline and Six Flags Corporation. Victor pointed out that within the railroad there were a large number of real estate parcels that could be carved out and sold. The estimate was approximately 10,000 separate parcels worth an estimated $1.3 billion, no small sum. There were also many properties being leased by the railroad generating millions in annual revenues.

The trustees agreed with Palmieri that these properties could be better managed for the benefit of the estate and entered into an agreement with him to build an organization that would take on this challenge. Victor Palmieri and Company was formed and would receive 2% of the gross proceed generated from the sale of these so called “non-operating” properties. Palmieri began building a team of real estate professionals and he also recognized he would need to create from scratch an information system to better manage and market these properties.

In order to explore what would be required to build these system, Palmieri invited several of the major consulting firms and largest accounting firms to a series of meetings to discuss requirements and approaches to this challenge. Among the invitees was a small operation research consulting firm located in Denville New Jersey. Russ White was the President of this small firm and one of the brightest people I’ve ever known. He attended all of these briefings.

Russ had an innate ability to understand and articulate the core problem that needed to be addressed. After this series of briefing Palmieri asked all the participants to submit proposal on their approach to the problem of creating the information systems that would be required by his new company. The larger firms put teams together to prepare detailed proposals that ran hundreds of pages and covered many extraneous topics.

Russ wrote a proposal that was one page and one paragraph in length. He simply stated the obvious problem that no information system or systems could be built until an inventory of the railroad was conducted to actually identify these 10,000 parcels and collect relevant information about them. The information Palmieri needed to manage and market these properties was co-mingled with the railroads records and information systems.

Bingo he had hit the problem that Palmieri faced squarely on the head. If you don’t know where these 10,000 parcels are and you can’t carve out critical information about them such as rent billing contracts, property taxes, book value and estimated market value, how were you going to manage or market them any better than the railroad’s own real estate department was attempting to do.

Our small firm won the contract and built this inventory data base, mapped the properties on railroad maps and generated a locater atlas using USGA maps to pro-actively market the properties. It took approximately a year to complete this inventory and build what became Palmieri’s property information system. Palmieri went on to sell all of these properties and this same system played a key role in breaking these properties out of the railroad when Penn Central’s rail properties were transferred to Conrail.

The lesson I learned from this experience was clear. Understand the problem your looking to solve and express it in simple and straight forward language that everyone can understand. I’ll be cover other topics in this series in the weeks to come.

William A. Crowell

Principal

Magellan Associates, LLC

　

What Makes Outsourcing Successful?

Outsourcing has been a hot topic for many years and much has been written about its pros and cons.  But what makes it successful?

Diane Frank of CIO recently wrote an article entitled “So You Inherited a Crummy Contract” and it made some excellent points.  Using experts (how could I disagree), realigning expectations (always an issue), implementing neutral governance (interesting???) and putting staff skin in th game (a gigantic problem).  But it also got me to thinking; What Makes For a Successful Outsourcing Relationship?

I’ve been involved in outsourced relationships dating back to Regan’s first term in the early ’80′s and I’ve seen great successes and unbelievable failures in both the public and private sectors.  My conclusion from all this is that the key to success or failure is in the “relationship”.

In a successful relationship there is mutual respect and trust between the outsourcer and their client.  This is difficult to achieve since most of the “Joe the Plumbers” view outsourcing in terms of either lost jobs or being unceremoniously transferred to work for a new company that they didn’t select.  Clearly there is some truth to both perspectives and it typically can take sometime for employees who remain with the client and those transferred to rebuild an atmosphere of trust.  Understanding this issue and taking steps to address it will typically fall to the CIO.

An approach, which seemed to work, was to make the simple statement that it didn’t matter who paid you, we all worked for the same customer.  It was then paramount to “walk the walk” everyday and deal identically and fairly with everyone.  In most cases, this open and collaborative style worked wonders.

Where this didn’t work, and not surprisingly it was in a public sectors environment where the concept of customer didn’t exist, was a situation where the relationship was driven by the “contract”.  The people involved were proud of the performance based contract they had written and felt their sole responsibility was to administer the contract.  There was no understanding of the views and concerns of the outsourcer and no concept that a relationship based upon mutual respect and trust was a two way street.

As a result of not working to develop this relationship, and both parties were equally responsible, an antagonistic relationship developed.  The outsourcer didn’t trust their client and felt they were constantly looking for ways to argue that a service they wanted was “free” or somehow covered in some arcane way by the contract.  The client felt that the outsourcer was constantly looking for way to “stick it to them”.  What made this situation almost comical was that planned spending levels for IT services under the contract were being under spent by millions of dollars.

Relationship is key.  Critically important to developing a productive relationship is deciding exactly  what kind of relationship is desired by the parties.  “Success” will be determined by how these expectations are either met or not met.  Also, over the term of the agreement these expectations can and will change making flexibility another key success factor.

Outsourcing can and does work and like all relationships: it is not an event, but a journey.

So if you’ve inherited a crummy outsourcing contract or if your entering into a new contract, make the development of the relationship based upon mutual respect and trust a top priority.  This means that both parties listen to and understand the other parties perspective.  As a Gartner consultant who worked for me once noted, if you want the outsourcer to perform a certain task “free”, it ain’t going to happen.  Consider bringing in a facilitator (i.e., neutral governance) if the relationship you want isn’t happening.

William A. Crowell, Principal

Magellan Associates, LLC

www.magellan-associates.com

CIO Perspective – Managing Complex Projects

Managing Complex Projects

I’ve been giving some thought to what I can offer from my 38 years of experience in IT starting as a consultant in an operations research firm and rising to the CIO position in both private and public sector organizations. What struck me was the continuing failure of highly complex systems projects even though we have invested millions in training project managers through such organizations as the Project Management Institute (PMI – http://www.pmi.org/). Michael Krigsman, a well respected expert in studying IT project failures, noted in recent blog (http://blogs.zdnet.com/projectfailures/?p-4967) that CRM projects have failed from a low of 18% in 2005 to 70% in 2002 and most recently was 47% in 2009. Why is this happening and what is failure?

Let’s take the latter issue first. Failure can be defined along several dimensions. Clearly a project started and then closed before delivering an operational systems is a failure. Significant cost or schedule overruns or systems that do not deliver the expected benefits can also be classified as failures or partial failures. Failures are all to familiar and I have seen a number of them during my career. For example, when I was the CIO of a medium sized mid-western publisher I inherited a book order fulfillment system project that meet all the above criteria. It was over budget, behind schedule and lacked the functionality the business required. It was also a technical disaster. The firm had contracted with a vendor whose application ran on one vendor’s hardware and wanted it to be converted to another vendor’s hardware, a much more complex and high risk endeavor than expected.

As we consider our options I noted that the company had contracted for a multi million dollar system for the book group that had sales of approximately $30.0 million, or about 3% of the firms overall sales. That didn’t seem to make sense. Were there lower cost and less complex commercial systems that would meet the businesses needs. The answer was yes, so we canceled the existing effort and had the lower cost system implemented within six months. The strategic error, which Michael discusses in his article referenced above, was an inappropriate IT strategy given the small size and lack of business complexity of the unit.

A certified PMI project manager would most likely have missed this key issue although they might have spotted the complex and high risk IT strategy being implemented. However, the fact is most project failures occur based on poor strategies (technical and business), conflicting goals, and lack of management/user support or even more important their active involvement in the project.

Additionally, I have encountered countless “bad contracts” especially in the public sector that lack the flexibility to adjust to changing situations. PMI’s Project Management Body of Knowledge (PMBOK Guide) notes that project requirements tend to become more clear as a projects progresses through the life cycle. Yet most contracts for new systems are pursued as fixed price/schedule efforts that are inconsistent with the above reality. I’ve learned that there needs to be a clause in contracts that allow the organization and its contractors to periodically review requirements, cost and schedules to see if resets are appropriate.

So why do so many projects continue to end in failure? It’s not a lack of project management tools, techniques, processes or procedures which are well documented in PMI’s PMBOK. It’s the lack of the latter skill “management” at all levels that contribute to failure. Although my experience is anecdotal and not scientific, as I look back over a long career, when there was good to great managers involved projects were amazingly successful and when poor or inexperienced managers were at the core of the initiative catastrophes were the end result.

In college, I learned that management involved planning, organizing, staffing directing and controlling the thing(s) that one was involved in managing. Applying these basic functions and the principles that underly them, I was successful in managing any number of highly complex projects early in my career before project management was a recognized field and way before a PMI and PMBOK existed. I’ll be focusing on management as it related to complex projects in future blogs on this topic.