PDS On Performance

performance improvement ideas and some common business sense

IT Project Success and Communication

Written By: Terry Merriman - Nov• 06•13

As an auditor specializing in information technology and internal control I spent a lot of time with IT Project Teams on a wide variety of application development and implementation efforts. Many times those efforts were less than stellar success stories and a few projects never made it to prime time.

When I think back on the successes and the failures I realize that I can identify many different conditions and situations that can make or break an IT project. The big determinant is always whether or not the customer got an application that satisfied the requirements, and functioned as desired and expected. In other words, did it meet the requirements as defined and modified, and was it user friendly? (Next to that big determinant were, did I get it within budget, and did I get it on time?)

If a development and implementation project didn’t meet those two criteria, my question was, “Why not?” So I’d drill down with the customer, and with the rest of the development team, with a few more “why” questions, only to find what too often I already knew. Customer requirements weren’t adequate, and customer acceptance testing was slim to non-existent. How can that happen within a group of professionals on both sides of the design effort? Were they not in the same meetings? Did they not agree on the requirements document? Did they not agree on the testing regimen? Did they not keep up with change requests?

Of course, they did all those things. What they didn’t necessarily realize is they ran smack into a major problem with human communication; believing they fully understood each other when they really didn’t. The IT professionals and the business professionals each assumed that the other understood precisely what was meant with each communication; each assumed specific activities were part of the other person’s normal routine in a development project. But in reality their expectations were not made specific to the project or explicit to each other; tasks weren’t done as expected, functionality wasn’t provided, requirements weren’t met, and the project ultimately failed to achieve the desired results.

Can every project failure be traced to ineffective communication? Of course not! A second major factor mentioned in so many studies and articles on IT project failure that I’ve lost count is Poor Project Management. Included in that topic were: failure to adequately define roles, failure to actively manage the team, and failure to provide timely and detailed progress reports to executives just to name a few. And you’ll note that once again effective communication is an underlying factor in poor project management.

What’s important here is to ensure that effective communication is established and maintained throughout the project so that poor communication will not become a factor in the failure of the project. Every team member needs to clearly understand his or her role in the project effort. All expectations related to the critical success factors in a project need to be clearly defined and agreed to by all parties.

Responsibilities as well as authority and accountability need to be explicitly delegated and accepted by each person. Business people need to understand the development model and developers need to understand the business model. Business people need to understand their specific responsibilities for acceptance and production testing and be involved early in the testing process. And every participant needs to understand that Go Live is not just a date; it’s the completion of production testing, training, and documentation in preparation for the public introduction of the new system. Does the massive failure of the Federal Exchange enrollment system for the Affordable Care Act ring any bells?

Helping to improve IT Project results through better communication … Terry