Leadership

Video: Five prerequisites for successful IT projects

According to some estimates, 68 percent of IT projects fail. That's a sobering statistic, but there are ways to stack the deck in favor of IT project success. Here are five strategies to overcome common problems that plague many IT projects.

According to some estimates, 68 percent of IT projects fail. That's a sobering statistic, but there are ways to stack the deck in favor of IT project success. This episode of Sanity Savers shares five strategies to help you overcome some of the common problems that plague many IT projects.

For those of you who prefer text to video, you can click the "Transcript" link underneath the video or you can read the original article from Michael Krigsman that this episode was based on: Five strategies for 2009 IT gold.

About

Jason Hiner is the Global Editor in Chief of TechRepublic and Global Long Form Editor of ZDNet. He is an award-winning journalist who writes about the people, products, and ideas that are revolutionizing the ways we live and work in the 21st century.

15 comments
gareths
gareths

It frustrates me how many of your articles are in video only format. Although I appreciate it can be easier to prepare and make articles more interesting I still prefer having control in text form. Is it possible to bring back a summary in text form to quickly run over your main points?

settle.g
settle.g

My experience has been even with a corporate sponsor the project can go south. But without a sponsor you can almost certainly count on project failure. Also, while sponsorship is good a sponsor with ownership is great! I feel it is imperative that management feels/knows that they are just as responsible for a project as IT. If management is essentially "ordering a drink" rather than partnering-up for mutual success then its time to bail or at least have a serious meeting with upper level management.

VEH
VEH

Corollary to Know your Goal: when the goal changes, change the project. I was involved in a multimillion dollar failed IT project as an SME initially, then later as a project manager (sort of--long story). The goal of the project should have changed fairly early when the PM at the time decided it would be easy to manipulate the output (RDB) for the company's largest customer. He didn't want to start over again with use cases/analysis because he assumed he knew what the other company did with the data--he didn't. It would cost too much to start over, he said. I was the idiot who later insisted that the application was unworkable and needed significant rework--programmers and IT guy from customer company agreed, but we were overruled by CIO who insisted everything was just fine. 5 years into project, I got my walking papers. So much for truth to power. I suspect CIO was covering his ass big time, and he subsequently left for another company before the project was killed. 7 years and unknown millions of $$ after initial proposal, project was killed. Original timeline of project was 10 months to completion.

Steven.Jones
Steven.Jones

The problem with management and stakeholders in general "ordering a drink" is that they don't allow proper analysis of the problems... they basically think they know what needs to be done and only provide the budget, resources, and timeline they feel appropriate to the solution they've identified. I'd be interested to see a statistic about the 60%+ of failed projects and how much time they spent during requirements and planning. You don't want to go through analysis-paralysis but you do want to spend enough quality time for the requirements cycle to make coding time effective.

jasonhiner
jasonhiner

I'd love to hear more. If you're willing to talk more about the story, click the Send Message link under my signature and drop me an e-mail.

snewton628
snewton628

After some 20 years working through large integration and / or migration projects, I've found just one reliable indicator of how well a large, multiple-business-unit project will go. At some point, a business unit middle manager will tell the project leadership "NO - my department will not accept the project as designed - large scale changes will need to be made". The reasons vary (too big a change to my department's processes, too much added to department workload, does not think solution will be successful, etc.). Some times the reasons are bogus, sometimes valid. Here is the indicator: if the project team is instructed to accommodate the manager's concerns, the project will fail. If the manager is looking for work the next morning, the project will succeed. It is a basic human impulse to to resist change imposed externally. And, once it is known that one manager was able to alter the project to limit or avoid change he or she did not welcome, the project will encounter an increasing number of "necessary changes" from other managers who will feel, correctly, that since one was able to force a design change, they should be able to as well. The result is a project that is no longer consistent, no longer focused on the corporate goals, is running behind schedule because of the re-work required in the plans or design (sometimes, even in completed code), and whose team morale has been damaged. But, if the manager is told that he or she has the option of supporting the original design or leaving, the message received throughout the organization is the bosses are serious about the project, and it would be a career-limiting move to not help it succeed. Of course, if the manager's concerns are both valid, and important, the project should be stopped, and a new project, with a design that avoids the manager's problems should be started, probably with a new project leadership team and, perhaps with a new group of business SMEs. But not recognizing the organizational impact of making large scale changes to a project's design in mid-effort has been the most consistent cause of project failure, at least within my experience. And no amount of "change management", "enhanced communications", or "gaining customer buy-in up front" changes that dynamic.

mafergus
mafergus

In my experience, 90% of the failed or sub-optomized project were due to scope creep. I have seen it come from sponsors, shareholders, and even internal IT (ever have the incredibly knowledgable techie who loves to please?) I do believe that communication does have a significant role to play, but the key for me is making sure that ALL of my people are on the same page. It is critical that EVERYONE on the project communicate any changes or suggestions that are made in reference to the project. The other major factor I witnessed was upper management getting locked into a strategy/vendor and disregarding the problems this choice would create. We once were looking at some software and it came down to two products. We choose the defective product that was slower and didn't scale because upper management believed that they "might" be able to fix their problems and we had recourse to sue, even though the other product actually worked! When this product was forced into production, the same upper managers wasted no time in blaming IT for selecting a terrible product.

walker.stephen
walker.stephen

In my organization documentation has saved me many times. It is so important to document disruption caused by the masters, especially if you serve multiple masters. When your people are asked to fight a fire or do some "quick" thing, document it. Send an email that Joe completed the "little" task for master X. When I present to stakeholders that a project schedule is slipping I have the paper trail of management decisions that caused that along the way. Even small interruptions can impact a project. I also shoot an email when a master has a "water cooler" conversation about the project. These conversations can become expectations on the stakeholder's part and a quick email thanking him for the conversation or ideas can really help control scope creep. Steve Walker Valdez International Corp OSHANet/OSHA Web Services | Project Manager Walker.Stephen@dol.gov "A goal without a plan is just a wish." Antoine de Saint-Exupery

ray.derkacz
ray.derkacz

Definately agree with all of this. For me, much of this is addressed by ensuring that projects establish comprehensive Terms of Reference (goal, objectives, scope, work breakdown, roles and responsibilities, key milestones, budget etc) and gaining full buy in by all stakeholders at the outset. This then needs to be treated as a living document subject to change control with all subsequent versions having full buy in.

marylou.vonwyl
marylou.vonwyl

In my experience, all of the points here are valid. The main issues, though, are usually the inability to initially scope out the project as accurately as possible, foreseeing issues that are bound to arise, the inability to admit when there are problems with the original scope, inflexibility in changing the scope along the way. It is also extremely important to consider the characters involved and the assorted powerplays, fear of losing one's baby and the inability to admit that someone was wrong. This is especially true now when so much is riding on quick, cost-effective solutions.

jasonhiner
jasonhiner

Your documentation/notes provides an excellent narrative for the progress of a project. Great idea. Do you keep this private or do you share it with the other people working on the project? Ever considered putting it on a Wiki and having everyone working on the project collaboratively add their notes?

walker.stephen
walker.stephen

A bunch of us are trying to get management on board with WIKI for this sort of thing. Currently we store stuff in sharedfolders and collaborative mailboxes. 90% of everything I do I confirm in email. I do keep selected email or communication private in the event of serious mudslinging. I am known as the king of CYA :)

philr
philr

I heartily agree with the above. Providing feed back in this way tips seniour managers off that overall governance within the company has become an issue. Scope creep may occur because the linkages between strategy formation and programme management need improving. Project briefs need to be reworked when significant changes have occured. Little wonder so many projects fail. Many managers wouldn't understand what the above is about! I produced a diagram for a Telco showing the linkages. A seniour adviser to the CEO said it was the most useful diagram he had seen. I think some pennies had dropped! ;-) Phil

Paul_Hardin
Paul_Hardin

In addition to documenting/validating conversations and expectations in email, as a project manager, the first thing I do on a new project is create a team listserv (actually multi-recipient alias). This is for the "working" members of the team as well as their immediate supervisors. I encourage team members to send ALL communications to the list, unless it is of a very sensitive nature. This has created "group-think," and makes sure anyone can contribute to any question, and ensures everyone has common focus throughout the project lifecycle. Only twice in 10 years has someone asked to be taken off the list because it was too much email or didn't apply to them. People LIKE to be in the loop!