Guide to successfully delivering IT projects
“The US alone spends $250 billion each year on IT projects for a total of approximately 175,000 projects”, says a Standish Group report. According to the report, a staggering 31% of the projects are canceled before it is completed and about 53% will cost 189% over its original budget. Think of the opportunity cost for the business. Put on your financial hat for a few minutes. Think about the source of funds for the business! Businesses either borrow (credit) or use equity (retained earnings or issue new equity). In the former the business is competing for cash with other businesses and government while in the latter cash for projects are competing with dividends. So if you are a shareholder you should be concerned about project costs overruns since it effects your dividend payout. Here are some other noteworthy comments from the report:
“Bridges are normally built on time, on budget and do not crash. On the other hand software never comes in on time or on-budget. Additionally, it always breaks down”
“… there is another difference between software failures and bridge failures, besides 3000 years of experience. When a bridge falls down, it is investigated and a report written on the cause of the failure. This is not so in the software industry where failures are covered up, ignored and/or rationalized. As a result we keep making the same mistakes over and over again.”
So why do IT projects fail? Some of the top project failure reasons cited are poor planning, unclear goals and objectives, unrealistic time or resource estimates, lack of executive support and user involvement, and failure to communicate and act as a team.
There is a wealth of literature on why projects fail. So instead of analyzing failure causes, let me share with you my observations on why projects succeed. But before we do that let’s define what a successful project is. A project is successful if it helps the business increase its gross margin; i.e. increase revenues and/or reduce costs (unless of course the project is undertaken to meet a regulatory need).
Project Planning
Did you know that a project’s success or failure is determined to a large extent even before the charter is signed? I am not referring to project planning here. What I am referring to is “portfolio and program planning”. That in turn is a function of the business’s strategic planning. If the organization lacks a strategic direction, then how would you expect to plan your project initiatives? Focusing on the right set of projects (your program) is the first step in getting projects done right. A program that does not fulfill a business need is doomed from the get go.
Business lead
Once you have determined your initiatives the management must choose strong business leads to guide the project team. Do not start a project without a strong business lead. Many strong initiatives have fallen apart due to lack of a strong business lead. By strong, I mean individuals who are passionate about what they do and have a strong motivation to see the successful project completion. These individuals are also subject matter experts and will help lead change within the business.
Trust - I’ll cover your back, you cover mine
All immediate stakeholders – project manager, sponsor, business analyst, the business lead and the rest of the IT team – must earn each others professional trust early on in the project. It is always helpful if the project manager and business analyst have domain knowledge. Having this knowledge will help grease up the communications lines between the business and IT. If they do not have the domain knowledge, it is recommended that they spend the time to learn the business. This IS one of the key success factors for successful project delivery.
Project Variability
No two projects are alike. If you realize this, then you understand that following a one-size-fits-all approach to project delivery will most likely result in failure. Unless it’s a report you are developing, software development is akin to navigating unchartered waters. This holds true even if you are deploying standard applications like ERP. Why? Look at your organization culture. Deploying software means change and with change comes resistance, possible change in business process and perhaps shuffling of labor. These things can kill your project.
Risk Management
Start talking about project risks with your business lead right at the outset. Use the What-If technique to identify risks. For every project fact, assumption and constraint you have identified ask “What-if”. For example, even if your requested resource is allocated for your project task that starts in four weeks, ask yourself, “what-if s/he is pulled into another higher priority project?” It has happened to me in the past. So better have a plan B. The recession over the last year could have been avoided only if people stopped to think, “What-if I am unable to find a buyer for the high risk mortgage backed assets?”.
Team buy-in
This is critical very early on in the project. Your team needs to understand the business problem it is trying to solve. Discuss this with your team at every opportunity. The team needs to be motivated to ensure they figure out innovative ways to solve the problem. I find face-to-face meetings are the right setting for this purpose. However, in this day of virtual project teams, face-to- face meetings might be a challenge. But use video conferencing or webcam. It is important that the team see and talk to each other every week. Also, use this opportunity to develop the team. If your sponsor is new to project management and your organization’s project delivery methodology, use these meetings to educate them and manage their expectations.
Develop in short phases
If you are navigating unchartered waters it is quite difficult to see around the corners. If it is difficult to see around the corners, then how can you plan for all risks? Software development is not akin to building bridges. So to mitigate risks, develop in short phases. Medium and large projects can get quite complex. Develop prototypes and let the business lead touch and feel the software. Let him/her get key users to play with the prototypes. Their feedback will help you deliver a stronger product. This will also help the business lead introduce leading change initiatives within the business. In addition to your goal of being on budget and on schedule, you need to also ensure the business can use the product help with their strategic objectives. If you use the “big bang” approach to deliver the product, the probability of project failure increases. Of course, you may have developed it to the design and the customer approved it in the beginning, but things change dynamically in business. Developing in phases means you can plan better thereby improving your schedule and budget estimates.
Implementation issues
This is the most important of all. The project manager and the business analyst have to be on site for the implementation. The business lead is going to be there, so why not you? Not being on site sends a wrong signal to the customer that there are other important things for you to do during this implementation phase. Remember the end user is going to use the software for the first time in a live environment. Even though they are trained, you need to be there to help them if things go awry. Your project and product of the project is unique. If there are issues, be in the trenches with the developers. This is your chances to showcase your leadership skills. Projects that do not deliver are canned during implementation and post implementation – not during planning and design.
Post implementation
Have a bare bones team to help resolve unforeseen issues as they arise once implemented. Respond to the end user questions and concerns in a timely fashion. Have the business analyst on site for the period of stabilization depending on the product complexity. Do not expect end users to read user manuals to figure things out. How many user guides have you read?
Ethics
As a project manager maintain the highest ethical standards. If you goofed, own it up. If your team goofs, take responsibility and get it fixed. Never ever get into the blame game. Take ownership and if possible develop your team with that attitude. Also never ever hide bad tidings from your sponsor and business lead. If there is an issue you have not planned for, it is better for them to know now than later. Provide the sponsor with the facts and possible solutions you have thought about. Let the next steps be an objective business decision instead of an emotional one. Watch out for unethical behavior from your team too – no padding, no gold plating.
As a project manager, your goal is to deliver a project that will benefit the business. You also cannot do it alone. You need to get the entire team pulling in the same direction working towards one goal. That can happen only if the team is motivated to the right things done right. Unless it is regulatory, your project deliverable is going to help the business increase gross margins. It is your moral responsibility to get it right the first time.
