How to Ensure the Success of IT Projects

Updated: March 29, 2010

Development Methodologies and Terminology

There are many different approaches toward IT development, Waterfall, Agile, RAD, Cleanroom, DSDM, and more. Each has committed, even fanatical adherents, but the presence of all these competing approaches really illustrates that this is tough problem for which there is no one-size-fits-all solution. This paper tries to avoid religious wars by providing advice that is applicable to any methodology.

Each approach includes some kind of specification and though the terminology and emphasis may vary, they all include some form of the following:

A Requirements Specification that describes what the project will do.

An Engineering specification that describes how it will do it.

To draw an analogy, the requirements specification describes the need for a 4 door passenger sedan that can cruise at 75mph. The engineering specification describes whether it will be a red Toyota Camry or blue Ford Taurus, any stereo equipment that will be included and when it will be delivered.

Project milestones, testing requirements, code architecture if custom coding is involved, maintenance, etc can all be included in sections of the Engineering specification, though different methodologies might call it something else.

Requirements Specification

The Requirements specification provides a clear definition of the project scope, and is the foundation from which the Engineering specification and hence priorities, project milestones, dependencies and other documents are derived.

It also provides the definition of success for the project, expressed in business terms, not IT terms. Specifically it must be expressed in terms of the business stakeholders and this illustrates why stakeholder identification is key, a missed stakeholder can kill the project.

The key to winning top management commitment is to address their needs. For a project to be successful it must address a particular "pain" in each affected stakeholder in a business process. By understanding stakeholder pains, an experienced project leader should be in a position to present what the project is hoping to achieve from different viewpoints and thus reach a common understanding which will eventually lead to everyone pulling into the same direction.

One critical issue that must be addressed in the Requirements Specification is what the system will be like to use. End users satisfaction is critical, yet it's common for leadership to be insulated from the concerns of the end-users because people are afraid to complain to the big boss.

Identify influential people in the organization and study if the project objectives and the individual power centers are in line. Else develop a strategy to bring them in line.

Effective communication

Schedule a meeting to discuss the project goals as laid out in the requirements specifications and confirm that the project is headed in the right direction before allocating the resources to get it there.

Have brief (15 minute) daily status meetings and longer weekly meetings to ensure that everyone is up to date with progress and to give the business managers the opportunity to suggest course corrections if the business needs have changes.

Keep stake holders up to date with project management software that automatically sends periodic updates and escalates issues when a dependency is late. When a team member leaves, the project management software may automatically assign their issues to a manger for a permanent re-assignment.

Maintain upward, downward and lateral communication and define a preferred method of communication for each stakeholder.

Engage people (inside and outside the project) and ignite the human spirit. Find people willing to deliver on what they commit to... and allow people the space to "contribute and make a difference.

Capture all communications, at all stages of the project, including relevant e-mails. These will help you when you create the final project handover documentation for the client.

Till the end of the project delivery you will face obstacles and in some cases pressure from the senior management, this is where assertive communication skills and a clear change management process are needed.

Engineering Specification

The Architecture section of engineering specification describes exactly how the requirements are going to be implemented.

Custom coding introduces the greatest level of risk so it should be avoided where possible. Code always contains bugs that take time and effort to flush out and despite the best efforts of some very smart people, with various development methodologies and IDE's, bug finding/fixing remains unpredictable. The typical ratio of costs for bug-fixing/maintenance compared to initial development to 4 to 1

If custom coding is required, set expectations that the project may take much longer than expected and budget for significant ongoing support/maintenance costs.

Avoid gold-plating as much as possible.

Project Time Line

Problems and unexpected events will always exist in a project, no matter how big or small. It's how the Project Manager deals with these elements that make the difference between success and disaster. You need someone tenacious, and fearless.

A rule of thumb is to plan in as much detail as you can to come up with a resource and time requirement, then double that estimate - it always takes longer as things always happen that you haven't planned for.

Contingency planning! When you create your project plan, add time for the 'unknowns' that you will discover along the way. Build a few extra hours into some tasks which add up to 1 or 2 days. And, most importantly, when you have your project definition kick off meeting, you must stress the importance of delivering on time and under budget.

Motivate your team by talking about the positive visibility you will have when you deliver on time.

Engage the team by asking for their commitment to communicate any delays they discover to the project manager right away. You must go around the round table and ask each person "do you agree with the project plan and how we need to manage it?" and "do you have ideas/suggestions for a better way to manage the project?" Write these two questions on the white board and as you ask each team member, put their initials that they agree. This visual aid - the white board or the poster paper will be remembered most. Then follow up with the meeting minutes. Make those brief but get the two questions in there and that the entire team agreed to this approach. Hold people accountable. Make sure you fully understand any delays they mention to you and document those by adding a note to the task in the project plan.

Early demos

A system cannot be fully demonstrated until it has been developed, but this is no excuse for not providing some kind of prototype. A software mockup without a working back-end can provide a reasonable facsimile to the planned system at a cost that is trivial compared to the actual system and should be included as an early milestone.

Here is a true story that illustrates what can happen if the end-user is not considered. A very large hospital in Los Angeles area implemented an Electronic Medical Record, spending $10M+ and a very large engineering effort. Everything was delivered as per the scope, budget and quality you can expect from a reputed vendor. Unfortunately, the clinicians refused to use the system forcing the hospital to scrap the system and write off the entire investment.

Effective training

Train the users in a test environment before it goes live. Gather feedback during this training and plan on modifying it based on their input.

Use Efficient Tools and do not Re-invent the Wheel

It is a lot easier to finish a race in 5 minutes if you start 10 yards from the finish line than if you start 10 miles back.

Enterprise IT projects generally require a web interface, auditability, dashboards, automated backups, security, web services/REST API's, reporting, searching, synchronization with other systems, data integrity constraints, export/import capabilities and more. The more core facilities are provided by the platform, the less needs to be developed.

Everyone is competing for the IT dollar and business managers will go outside if they cannot get the level of responsiveness that they need internally.

Example: When a business manager asked his IT department for a quote on developing a tool for managing COCOM compliance, he was told that it would take about six months effort using Lotus Notes. An outside vendor quoted him three weeks as a fixed price contract and got the job. From the perspective of the business manager, IT failed before they even started.

Yet the IT department could have installed the vendor's framework on their own server and configured it in exactly the same way. Apart from needing a week of training to come up to speed on the technology, they would have been in exactly the same starting position and when IT delivers a finished product in less than a month, they look like heroes.

Another example: At another company, a development manager was planning, and had actually begun writing, a comprehensive document on the coding standards they should use for J2EE development. Twenty minutes research on Amazon brought an entire book on coding standards. Incidentally, the critical tool in this case was not so much the availability of the book, but the rating system that made it easy to find the definitive work on the topic and so avoided a lot of argument.

QA Process

A good QA process is very important. Ensuring a level of quality is in place reduces negative perceptions from the end users of failed projects. The QA team ensures that requirements and functionality are in tack before end users get a hold of the product. It only takes one negative view to domino the perception that the project is a failure.

Risk Management

Prepare for the worst. Hardware may fail; users may demand changes and staff may be unable to meet their commitments.

Have a plan B in place before you need it, not when disaster strikes and people start slipping into panic mode.

Be willing to take calculated risks and be transparent and open regarding all project setbacks and escalate in good time. Bad news can be dealt with if it is early. Bad news late is a disaster!

Gather sufficient information about past projects in the organization, their success stories and disaster stories. Analyze reasons for success and failure and make use of your assessment in the current project

Obtain estimates for remaining work on a task in workdays rather than % complete.

Integrated Change Control

True success includes adoption of change in the trenches. Make sure that your requirements translate into change such that the outcome is actually adopted.

Have a well documented change management process and get it signed off from the client; otherwise clients will believe that it is their right to change the requirements whenever they want without understanding the process.

Making prudent use of document and/or code repositories for collaboration and unification across development teams is a great help for successful delivery of projects. By using knowledge base and search tools the iterative process being done by collaborative teams can be managed throughout the project life-cycle. Some application development environments come with these tools built in. Training and full use of such programs will certainly keep the scope, design, and development in check as everything is run through the disparate teams on the way to implementation and delivery. Many more eyes are able to quickly examine the routes developers are taking at any time, which will give the opportunity to head off potential scope creep and re-coding of available classes and modules.

Effective Project Manager

Having an effective project manager is critical and this paper describes actions they can take to ensure the success of the project. The following suggestions are intended to help you hire an effective project manager or indeed other IT employees, but first lets clear up a couple of myths:

Myth 1: Interviews Are Effective

The exact number depends on the interviewer, but researchers have found that typical interview accuracy rates are only 30% better than random selection. Further, there is almost no correlation between how good someone thinks they are at interviewing and how effective they are. If you have never hired a dud employee, congratulations! If you have, read on.

Myth 2: Checking References Improves Outcomes

Not only are many employers too afraid of lawsuits to give bad references, some will even give excellent references to help rid themselves of problem employees. In general the only thing harder than finding a good employee is finding a bad reference.

Prior experience is an excellent indicator of how much money employees will want, but a poor indicator of how well they will actually perform.

A More Efficient Process

Of course, interviews, reference and background checks are an essential part of the hiring process, but they should not be the sole criteria. Here is a suggested process:

Create custom web forms for each job opening and set up business rules to prioritize and/or auto-reject candidates based upon information provided in the form. For example, you can ask them to take a quick online test and include the result in their application. Appropriate rules can eliminate 70-90% of the candidates without any effort on your part.

Ask the remaining candidates them to take an online aptitude test for that specific position. Depending on the position, only the top 10-20% progress to the next stage.

Only hire candidates who achieve unanimous buy-in from team members. Immediately make a job offer, contingent upon reference, credit and criminal background checks. Do not keep them waiting or another employer may step in.

A disciplined, automated hiring process can not only free up your time and ensure you find the best possible candidate, it is objective and can be audited to demonstrate an absence of bias.

Team resourced with the right expertise

This might seem obvious, yet projects often flounder because the participants did not have the necessary expertise.

The Milestones section of the Engineering Specification should include a description of the required expertise to meet this milestone and which team members will provide it. Where applicable, these team members should have objective test results to confirm they actually have the required expertise.

Transparent Work Flow

The tool should make it clear what the workflow is for any given process and how this process has been followed in any particular instance. Since most people are not programmers, this implies that the workflow representation and its application must be accessible to non-coders.

Infrastructure

Many IT professionals who are "software focused" don't include this topic in their planning - and so many projects that do a great job at meeting the functional requirements fail upon implementation.

The hardware infrastructure at many companies is in bad shape even before new loads are introduced, with predictable results.

Plan for at least double the "expected peak" load and assume that any given piece of hardware, including motherboards will fail

An assessment of the state of the starting (i.e. current) infrastructure should occur at the start of a major software project. As many software professionals do not have strong infrastructure experience, it is wise to hire a consulting firm or use a IT Infrastructure Assessment tool to conduct an objective survey of the reliability, utilization, performance, capacity, and design of the major components.

A key outcome is to identify the risk of the current infrastructure, it's current weaknesses, and provide data to forecast the loading of the components when the new (additional) application(s) are fully deployed.

Experience demonstrates that lack of capacity or poor infrastructure design leads to high latency, application timeouts, and random errors due to high loads that are nearly impossible to troubleshoot - yet consume a large amount of software developer resources.

Capacity planning is a key process that many small and medium size organizations do not perform on a regular basis. Subjects to be included in a capacity plan should include:

• Servers
• Web Servers
• Storage
• Networks
• Desktops
• Printing
• Database
• Telephony
• Data Center

Supplier Management

Build performance clauses into the contract, including the ability to walk away without paying if they are significantly late.

In order to avoid re-inventing the wheel, most IT projects will be built upon third party software. Here is a vendor checklist to consider for the software and supplier, though not all items are relevant to all projects.

Auditability

The system must be auditable in multiple senses to ensure compliance with Sarbanes-Oxley and other regulations. It must make it easy to show an auditor what a defined business process is, how the system enforces the process, and how the process has been followed in any particular instance. Further, the solution should make it possible to capture and collate data, such as who logged in, what IP address they came from, what records they viewed, edited, etc.

Integration

The solution should include pre-built integration with standard technologies, such as LDAP/Active Directory and MS Exchange. It should also support a robust set of APIs and scripting options, including Web Services. Ideally, even the source code should be accessible - not that you'd want to change it any more than you'd want to use an emergency parachute, but it is nice to have the option.

Adaptability

Once the system has proven itself in the initial deployment, it should be easily extensible to other business areas. So the data models, business rules, workflows, access permissions, and data input forms must be fully and rapidly customizable.

Scalability

The solution must scale to support thousands of current users, the update of hundreds of thousands of records per hour, and databases containing tens of millions of records, without requiring non-commodity hardware.

Security

The system must support a fine-grained security model for precise access control. The software platform, and if SaaS based, the hosting infrastructure, should be subject to regular security audits from an independent firm and the vendor should make the results available.

Uptime

For SaaS based products, vendors provide up-time guarantees that reflect their confidence in the availability of the service. Some vendors just offer a pro-rata refund, while others return the entire cost of that month's service if the target up-time is not met. If the product is installed in-house, it should support high availability options so that service can continue even in the event of a motherboard failure.

Reporting

The system must support dashboards, charts, and reports that provide quick insight into business processes. But passive access to information is not always enough, so it should also support the creation of business rules that provide active notification of any problems.

Standards Compliance

The system should support standards such as HIPPA, ADA, ITIL, and CFR 21 Part 11.

Platform Choice

The vendor should offer a SaaS option so that customers don't need to provision a server to get going. Once the solution has proven itself, it should be movable to their choice of in-house Linux or Windows server to allow full integration with sensitive back-end systems without impacting the firewall.

Web Based to Reduce Maintenance

The product should be 100% web-based so that no installation or upgrading of client software is required. It must support the customer's choice of browser.

Backups

System backups should be fully automated and include everything necessary to move the entire deployment to another server or to restore in case of disaster.

Upgrades

Upgrades should require little effort and must allow migration from any revision to any later revision without affecting customizations.

Cost

The cost to get started must be reasonable and the product should provide a rapid ROI, ideally within the first few months of use. Getting a reasonably complex production system up and running should be reasonable (e.g. $50,000) and extending the system to cover new processes should be low. The cost structure should be simple and inclusive, without hidden extras or per module or per function charges every time you want to extend the system.

Vendor Independence

IT staff should be able to extend and maintain the system themselves after training, rather than tying the company to long-term dependence on $200-per-hour consultants. Ideally, the training time should be short. Systems designed to be maintained by the users may require a week of training to reach proficiency, whereas those designed without this criterion in mind may require over a month of training and carry increased effort/risks when making changes.

Company Stability

The vendor should have a ten-year or more history of providing enterprise solutions. For CIOs of large companies, the vendor's track record with other Fortune 500 companies is most relevant. For start-ups, experience with small companies is of greater interest. The vendor should be financially sound and profitable.

Low Risk

The vendor should be able to describe exactly how the software addresses current business need(s) and demonstrate it running this exact process prior to purchase.

The vendor should be willing to commit to a fixed-price implementation for the entire project based on a mutually agreed specification.

Different vendors may offer different forms of refund if a project fails, ranging from a credit towards additional software purchases, to a full cash refund of all software costs and consulting services. The strength of the warranty indicates the vendor's confidence in their software and implementation services.

Vendor Summary

Different CIOs may prioritize their requirements differently from this list, but it should serve as a useful starting point. The extent to which these requirements are supported varies widely among vendors.