Three reasons why most IT projects fail (to meet expectations.)

There are hundreds of factors that can affect the outcome of any IT project. After years of managing all types of projects I have come to the conclusion that failure is often due to a lack of balance between three competing forces.

  • How fast you try to finish the project.
  • How frugal (or cheap) you are being.
  • How much you want the system to do.

There are many variations on the three legged stool analogy but they all state that you cannot have all three “legs.” I don’t agree. In fact, this type of thinking is dangerous. It only deals in extremes.

With so many things to go wrong, it is hard to get it right.

With so many things to go wrong, it is hard to get it right.

Although it is true you cannot build a highly complex system in days for a dime, you can build a system that has reasonable functionality in a reasonable time on a reasonable budget. The minute you move one of those factors closer to the extreme, the more likely you are to have a failed project.

So what is reasonable?

Reasonable is subjective and changes with each project. There is no magic formula to figure out what is reasonable. Each project does tend to have one “set in stone” factor.

  • If I need to replace my routers because they are old, and I don’t need any new functionality, then I know for sure what my functional requirements are. Now I only have to find a reasonable timeline and budget.
  • If I need to replace a CRM system with something new and unknown, I can set an upper and lower budget for the project and then keep the timeline and functional requirements within that budget.
  • If a product, like Windows XP, is being retired and must be replaced, I have a firm timeline. I only need to find the right balance between cost and functionality.

In most cases you only have to balance two factors, not all three.

Finding balance

This is not a joke: If everyone is a little unhappy, you have probably done well. Balance is about finding the middle ground which means someone will be disappointed. The budget conscious will feel like it was slightly more expensive than they wanted. The time conscious will feel it took too long. The rest will feel like some “nice to have” features are missing. Although this sounds bad, it is really project nirvana.

If one group is really happy, you focused too much on them. You gave them too much which throws the project out of balance. You have all the killer features but blew the budget or timeline.

Balancing a moving target

The most complicated projects I have worked on are software implementations like CRM or ERP. They always have an incomplete list of functional requirements. They always have a budget and timeline based on estimates from a vendor with an unclear understanding of the unclear requirements. The entire project is based on nothing but guesses which is why they often fail to meet expectations. The requirements always grow, the budget always grows, and the timeline always grows yet both the vendor and customer blame each other for the overage.

For projects like this, you must have (or be) a project manager that keeps all three factors in everyone’s mind at all times. You can’t add features without adding time and budget. You can’t set a deadline in stone unless you also freeze your requirements.

Who owns the leg

Just to make things more difficult, each leg of the stool, or factor, is generally managed by different groups. A senior manager or executive may be in charge of the budget while the IT team might be in charge of the timeline while some department head may be in charge of the functional requirements. They each look almost exclusively at their leg of the stool and say “My leg is the wrong length, fix it!” They don’t always care about the other legs and that means you have to balance requirements by getting three or more groups to understand each other’s needs. The project manager may need a degree in counseling to get some groups to work well with each other. If you can’t get all the groups to work together, the project will almost certainly fail to meet expectations.

Think balance, every day

You have to start a project in a balanced state. You have to consider how every decision you make affects the balance of the project. You have to communicate how each decision affects the project balance. If you end with a reasonable balance between cost, timeline, and functionality you hit a very small moving target. It feels like nothing less than a miracle.

Challenges to implementing Office 365 E3

Imagine having multiple domains in multiple forests with multiple Exchange servers. Some of the domains are still running Windows 2003 domain controllers. Many of the desktops are running Windows XP. Microsoft Office was purchased OEM so end users have version running from 2000 to 2013. Several smaller business units are running Small Business Server 2003 while the larger use Exchange 2003 and 2007. You have about 1,000 users in multiple locations being managed by multiple IT departments.

And yes, it is 2014. Years of neglect have created this “diverse” computing environment. This may not represent your company but you probably have at least one of these issues to deal with if you need to upgrade your Exchange server. Doing nothing isn’t an option so what do you do?

Single Sign On

You probably want single sign on for your domain. Honestly, many of the features that make Office 365 useful work best with single sign on. Some of these steps can be avoided if you want your users to have one account for email and another to log into their computer.

Single Sign On will require Active Directory Federation Service to be installed and working in your domain or in the cloud. Once working, whatever username and password you use to sign into your computer are what you will use to sign in to your Office 365 account. When you disable an account in AD, it will be disabled in Office 365. 

You can convert from Single Sign On to separate accounts but you cannot go from separate accounts to SSO.  Decide early if SSO is important to you because there is no going back. 

Exchange 2013

Office 365 is essentially Exchange 2013. You will need Exchange 2010 or better to migrate to Office 365. If you are running Exchange 2010, you may not need to do any more upgrading, if not, you will be installing Exchange 2013. That means your domain and forest have to be ready for Exchange 2013. The system requirements can be found here: http://technet.microsoft.com/en-us/library/aa996719(v=exchg.150).aspx

Remember:

  • you cannot install Office 2013 on Windows XP. This is probably good as it forces you to upgrade or replace all your Windows XP machines but it can be painful if you have a lot of them.
  • Office 2007 is the earliest version that works with Office 365. (If you are buying Office 365 E3, you get a copy of Office 2013 for every user.)
  • Office 365 requires Internet Explorer 9+ or other browsers. Again, you can’t run IE 9 on XP.
  • Exchange 2013 cannot coexist with Exchange 2003 or earlier.

So, to use Office 365 or Exchange 2013, you must upgrade or replace your Windows XP machines with Windows 7 or 8. (Vista would work as well by why torture yourself?) You must also upgrade to Office 2007 or better or people will have trouble using email during the migration. Lastly, Exchange must be 2010 or later.

Active Directory

Although it appears that you could keep multiple domains in multiple forests, all the consultants I have talked to recommend against it. If you ended up with multiple forests through acquisitions or accident, this us the time to collapse into a single forest. Once you integrate into Office 365, it will be difficult collapse domains or forests.

In my early career, I was a consultant that specialized in Active Directory migrations. It has been years since I have done one and things have changed. Unless you do Active Directory migrations all the time, I suggest hiring a high quality consulting firm to help.

Once your domain and forest are running in Windows 2008 mode or better, you can proceed with the migration.

How to Migrate to Office 365

It should be obvious by now the project will be more complex than you expected.

Get your Active Directory in Order

The first step is to take the time to get AD updated and in good working order. Collapse any unwanted domains and forests and update it to at least Windows 2008 mode.

Get rid of legacy systems

Windows XP and Office 2003 must go. The most difficult issue to overcome will be how to upgrade Office before you purchase Office 365. If you buy Office OEM or through volume licensing you are wasting money. If you buy Office 365 months before you start using it, you are wasting money.  This is certainly a disincentive to upgrade to Office 365. It would be worth your time to try to negotiate a temporary license for Office to use during the migration.

Migrate to Office 365

The actual migration to Office 365 will be simple compared to the prerequisites. Again, unless you have deep Exchange expertise, hire a consultant. Every situation is a little different and only people that do these migrations regularly can predict how decisions you make will affect you.

I should point out that I am not a consultant … I am the guy that hires the consultants. I am all for saving money but email is important enough to do right.

It might not be this hard

If you stay caught up with technology, are running Windows 7 or better everywhere, have your Active Directory in a mode that was created in the last five years, and avoid 10 year old software, you may be able to migrate with only a little preparation. On the other hand, if you work for a company that only spends money on IT when they have to, the move to Exchange 2012 or Office 365 is going to be very expensive. This is really a good argument for keeping things up to date because in the end … you will have to upgrade everything.