Project Management Institute

Systems integration pitfalls and what you can do about them!

img

CLIENT/SERVER TECHNOLOGY

Tom Richardson

Want to know why so many systems integration projects fail? I‘ve been involved in integration projects for 13 years, spanning 50+ projects for Andersen Consulting and The Systems Consulting Group. You might be surprised at the things that continue to undermine projects and how simple they are to fix.

Project Management and Control

It is amazing how many integration projects are initiated without any control mechanisms in place. It is, understandably, not the most exciting part of a project, but without solid project management and control techniques, integration projects are doomed before they start. Here are the cliff notes of good, solid project management and control techniques:

Determine and Remember the Project Objective. It is important to identify the main project objective before any work begins. Too many times project teams lose focus of the overall goal. They get distracted by other important but less critical objectives. As an example, let's assume that four basic objectives have been identified prior to the start of a project. The first is to deliver a quality working system in the shortest possible time. The second is to pilot a leading-edge technology. The third is to bring a group of current employees up to speed with this new technology. And the fourth objective is to keep costs at an absolute minimum.

 

This article is the first in a new PM Network feature column on Open Systems and Client/Server Technology. Four times a year we'll publish columns on various aspects of systems integration. The feature editor is Tom Ingram, a certified PMP and regular contributor to PMI publications. Tom is with Systems Consulting Group in Carrollton, Texas, and has worked exclusively in the Open Systems arena (Client/Server, Unix, LANs, etc.) since 1983. We look forward to advice that will help us all have successful systems projects.

Jim Pennypacker, Editor-in-Chief

If a primary objective of these four is not determined, problems could arise down the road. For example, if the No. 1 objective is to implement a working system as fast as possible, the third and fourth objectives may not be met. In this scenario it might make sense to outsource the development to an experienced systems integrator. It may cost a little more but the system will be in place sooner than if done using in-house personnel.

Appoint One Main Project Leader. Establish one person who will have overall control of the project. There can be joint project leaders, but one person must have overall control.

Assign Formal Roles and Responsibilities. Each member of the project team must have their roles and responsibilities specifically defined at the beginning of the project. Additionally, each member of the project should fill out a “project objective form” detailing their specific objectives on the project. If there are many companies involved, this can be done at the company level.

Weekly Status. These reports must be prepared without exception and must reflect the actual status of the project. The authors must understand that glossing over issues to avoid the wrath of others is asking for trouble. The truth will hurt less now than later. Copy everyone on the status reports (even if they do not want them) and solicit feedback when required.

Time Control. In my experience, very few companies do more than merely collect and accumulate time spent on projects. Tracking two simple variances can help identify problems before they become unmanageable. The variances are:

1. Effort Variance – the difference between the original estimate and the sum of the actual time spent and the estimate to complete.

2. Staffing Variance – the difference between the amount of time spent on the project minus the amount of time scheduled to be spent on the project at that point in time.

Adding the two variances together will indicate how the project is tracking to a scheduled completion date. There are many project management software products on the market that can accomplish this easily.

Editor's Note: The Project Management Body of Knowledge (PMBOK) suggests concepts such as earned value, estimate at completion and schedule variance ratios to accomplish the same goal. An understanding of the underlying issues of time and scheduling is far more important than the specific tool used. For this reason, I discourage the use of project management software for the new project manager unless strong training is undertaken. Most project software allows new users to enter large amounts of data with very little training. There can be a “black box” quality to the output, however, and the project manager may not understand WHY the results are what they are. If the novice project manager cannot independently verify the results based on an understanding of the fundamentals, a false sense of security can arise. In additon, much time can be wasted on data input and reporting with questionable output. To help new project managers learn the fundamentals, I recommend using simple spreadsheets developed by the project managers themselves.

Scope Creep. The bottom line here is that the IS (Information Systems) community is too willing to bend when it comes to users begging and pleading to make changes to the original scope. Once scope has been defined, you've got to be tough. Every single exception to the plan has to be highlighted, assessed for its impact on the project, and prioritized for approval.

Delivery Time. If it takes longer than six to seven months to have a tangible usable deliverable from the system—it's too long. Manage the phases of the project to ensure that the users get something concrete within six to seven months and you can post a win on the board.

Quality Assurance. This, in most project sponsor's eyes, is nice to have. If, by chance, time was originally budgeted for quality assurance reviews, they are, ironically, soon deleted at the first sign of trouble. Members of the project team are often too caught up with the specifics of the project to identify unforeseen pitfalls. Having the project reviewed by a group outside the development team is a great way to mitigate certain risks. Don't bypass the QA reviews!

Commitment and Communication. This refers to user commitment to the project. If the IS community could get the users of their projects to commit one to three weeks up-front (depending on the size of the project) for uninterrupted scope setting, prototyping and requirements definition, many project failures could be eliminated. Too many times systems integration projects are initiated without a full understanding of the mission. Additionally, once the requirements are defined, constant communication with the users is imperative. Don't go off and develop the system without further input from the users. They need to be involved from start to finish. Get their fingerprints and signoff on all deliverables.

Structured, Proven Methods. If you are traveling somewhere new and you don't have a good road map, you are going to get lost. With Client/Server and Open Systems technology, many clients think they can accomplish the project without formal structure or adherence to a methodology. Fifty percent of the projects that I have seen have gotten into significant trouble by using a highlevel “roadmap” (methodology), or none at all. When in doubt, experience teaches us to lean toward structure and proven methods.

Editor's Note: Much of American management culture has been moving away from structured, authoritarian approaches and toward collaberative, cooperative, buy-in oriented techniques that seek to minimize conflict and bad feelings. Most of us applaud these moves, but we must remember that projects are very different from day-today operations. Projects are, by definition, unique, one-time events. Every experience I have had over 13 years and 71 Client/Server projects tells me that structured, proven methods are necessary, despite vendor ease-of-use claims. In most cases, nearly everyone on the project team will be inexperienced with the technology and not know what it really takes to do a project right.

The best analogy I can find is that of raising our children. Kids are inexperienced at the issues of life. What happens when we are not willing to enforce discipline and structure with children? Most would agree that the warm, fuzzy, good feelings, avoid conflict, whatever-makes-you-happy approach to parenting is a prescription for disaster. Parents and executives overseeing projects often believe that they are too busy to enforce discipline and oversee structure. The high problem rate with both children and system integration projects tells us to examine our priorities. I strongly believe that these projects should not be undertaken unless priority is given to the structure, discipline and management time necessary to do it right. As with parenting, project wisdom begins with the question “How can I find out what it takes to do it right?”

Budgeting/Estimating. You wouldn't build a house without knowing the cost up-front, would you? In order to get that cost, you have to spend ample time with the architect to conceptually design all the specifics before the builder can price it. Too often, IS is forced into the position of telling the users/sponsors what the system will cost before knowing all the features and functions to be implemented. Spend the time up-front in order to get an accurate picture of what is to be developed. See commitment above.)

Editor's Note: The PMBOK recommends a standard for structuring project phases and the relative time spent in each phase:

(C) Concept (5 percent of project budget): This phase investigates feasibility, order-of-magnitude estimates and management authorization to proceed to the next phase.

(D) Development (20 percent of project budget): Do not confuse this phase with software development. This is the time where requirements are defined, project plans and work breakdown structures are developed and estimates are refined with much greater accuracy.

(E) Execution (70 percent of project budget): This is the phase where the actual work gets done. The single biggest and most-repeated mistake that I have seen is skipping the development phase, buying the hardware and software and diving in to execution without adequate planning and controls.

(F) Finish (5 percent of project budget): Finishing sign-offs, documenting project results, evaluations, and archiving the project records are the key tasks in the final phase. A fundamental concept of the PMBOK is that of using actual data from project histories to support estimates for new projects.

Rapport. If you don't have trust and respect, teamwork will never occur. The way to develop rapport is to create a plan. Just as you create a work plan for the project tasks, create a rapport-building plan with project members. For a good reference that describes this process, pick up a copy of “Win Win Negotiating.” It is well worth the 30 minutes it takes to read it.

Choose the Right Systems Integrator. Here are some tips and things to consider when selecting a good systems integrator:

  • Size of integrator and years in existence. This is a good indicator of stability and value to the marketplace.
  • Have they been recognized for their achievements? This would include publications such as Business Communications Review, Inc. Magazine and Datamation, or companies such as Microsoft and Lotus. Also, are any of the major industry research firms aware of them?
  • Areas of advertised expertise. This is key to understanding the company's main mission and how that fits into what you are asking them to do. This is also a key factor in determining your position of strength. For instance, if the integrator's area of expertise is in manufacturing systems and they are proposing to help you on payroll human resource systems, that should raise some flags.
  • Client base. Ask who their clients are before asking for references. This will give you a feel for the types of companies the integrator has worked with. It will also tell you where you as a prospect fit into their client base—top, middle, or bottom. You need this information to determine what type of leverage you have. If you are using a hot technology or if this is a pilot project that could lead to more work, the more leverage you have. Ask for references after you have seen their client list.
  • Rate structure. You need to know how they price projects. If they do fixed fee, be very careful. Very few companies know how to fix fee projects correctly and, as a result, you either overpay or, worse, suffer the consequences of a systems integrator who loses money.
  • Guarantees. Typically, integrators do not give guarantees. However, you can get them if you ask. The key is to determine a cutover period where support ends and you, the client, take over.
  • Support and maintenance. Many companies want the option to outsource the maintenance and support of the system once it is completed. If an integrator offers this, it can be very attractive.
  • Quality assurance program. Examine how the integrator ensures quality. Do they have a formal program?

Editor's note: Take the trouble to investigate the integrator's financial stability. Will the integrator's salespeople let their controller openly discuss the firm's financial position with you? Aside from obvious solvency questions such as debt-to-equity, profitability and cash flow, ask about their average days of outstanding receivables (happy clients pay their bills!). img

 

Tom Richardson was a senior manager with Andersen Consulting for six years before co-founding the Systems Consulting Group in 1988. SCG was recognized by Inc. Magazine as one of the top 500 fastest growing firms in 1993.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network ● July 1995

Advertisement

Advertisement

Related Content

Advertisement