On a regular basis I read about IT Projects that have gone badly wrong, leading to long delays, and budget blow outs. When preparing for any email migration project, I am a big fan of reminding everyone how not to run an IT project !
This article focuses on New South Wales (NSW) in Australia, where a number of Federal Government IT Projects were consistently failing. I would prefer that any Federal Government is able to run IT Projects on-time and on-budget. Then spend the millions of dollars not wasted, on worthwhile initiatives for the community.
The acting NSW Auditor General, Peter Achterstraat, was more than qualified to provide an insight on why so many of his State’s IT projects were going awry. On retiring, he kindly published his thoughts, to allow future projects to avoid the same mistakes. Every business should read this free information before embarking on an email migration project. From what I have seen, there are many people who do not follow his simple advice.
I have re-published his 12 key items (in bold), and provided a personal commentary (in italics) related to email migration projects.
At the end of this article I have also listed ingredients of a successful IT project – again, from Peter Achterstraat.
12 Reasons Why Government IT Projects Fail
- A poor initial business case
Often I have been brought into an email migration project, and there has been no business case. It is important to state why the project is being done. This provides a focus, and a clear goal. An example could be, “Migrate off Domino to Office 365, to reduce IT operational costs by 25% before 2019”.
- Unclear statements of expected outcomes
This is similar to a lack of requirements. A detailed list of requirements is invaluable to any email migration project. It provides a concise set of goals and metrics that anyone can understand.
- Lack of senior management buy-in
A common failing, whereby the CIO is not actively supporting the email migration project, with a highly visible presence throughout the project. Strong leadership from the C level is required. This is vital, as there will be times in any email migration that major decisions will need to be taken, that maybe not all parties will agree on. No project should start without this support commitment.
- Inadequate gateway reviews
This is a basic project management structure that is required, and a CIO needs to be part of the gateway review, along with all other key stakeholders in the project. On one major email migration project I was leading, I was excluded from the gateway reviews, with the Project Manager attending by themselves with the CIO. It became clear that the CIO was being told a false story by the project manager, which led to bigger problems. Any issues need to be on the table to be address quickly, by all stakeholders.
- Poor communication
Clear, regular, communication is essential, and not just via emails. Use the intranet to post regular news updates on the project. This is also useful for providing an alternate means of getting communications to staff other than email. Pin notices up in kitchens and common areas as well. Do not let rumours fill the void of lack of communication.
- Inadequate stakeholder engagement
Some stakeholders can get ignored, for many reasons. All key parties need to be involved, to contribute to a successful project. If a stakeholder is not involved, that is usually for a reason, that can be raised as a risk.
- Scope creep (or in many cases ‘scope gallop’)
Email migration projects will often encounter unforeseen items that need addressing. These can be tackled, but via a formal change process, to allow for budget/timelines to be addressed. Without this control, the project can become much larger than planned. Maybe, new projects are needed to cover new requirements ?
- Conflicts of interest
It is not helpful if a member of the project team has a political interest in the work going badly. I have seen this happen. Better to call this out early, and consider bringing in external people to do all the project work. Bring in the experts to do the email migration project.
- Optimism bias when assessing prospective benefits
Any email migration project team should have independent experts present, to provide a balanced viewpoint on any prospective benefits. This would typically be at the start of the project, when the business case is being put together. A realistic business case will benefit the project.
- Group think
Lack of leadership defaults to the situation whereby the wider project group having to reach consensus on all big decisions. This is really bad news and leads to massive delays as each point is debated at length. No one wants to stick their neck out and make a decision. This can arise if the required technical decision maker wants to protect their role in the company and avoid making a bad decision. Better for them to decide to not to decide on anything ! Terrible ! Get someone else to make the decisions – the project sponsor at C level needs to sort this. Another situation that can arise is the project manager starts making decisions, as they are frustrated at the lack of decisions being made – to try and keep to the project schedule. All of this leads to a low quality email migration project.
- Lack of appreciation of the ‘big picture’
A properly structured email migration project team should allow the right people to step back and track the work at a higher level. Ensuring the project requirements are being met is important, and allows the project to stay on track. Regular status meetings can help here, as can active involvement of the C level project sponsor.
- Decision-makers being too imbedded in the project so they can’t see the forest for the trees.
There needs to be strong technical leadership, including an architect level person to ensure the project will meet expected outcomes.
Successful Email Migration Project
Achterstraat stated that there are common traits for a successful IT Project. He listed an example, which I have reproduced, and provided a commentary.
- Clear distinction on who is managing and who is leading the project. Where the same group of people or team attempts to undertake all three functions – leadership, project management and governance – the functions can become blurred and not properly executed.
In my opinion, the project manager must manage, and not lead technically. The Technical Lead must sit higher up than the project manager, as only they have the unique skill-set required for success. If the project manager is making technical decisions then that is a big warning flag to me.
Conclusion
This article provides invaluable free advice for any email migration project. The best way to learn is from other’s mistakes. A lot of what is said here is common sense, but time and time again we see IT projects fail by not doing what they should do. Invest a small amount of money in an experienced email migration consultant, to ensure your project is successful.
Feel free to read other articles that cover Peter Achterstraat, and his views on IT projects.
http://www.itnews.com.au/news/twelve-reasons-government-projects-fail-357915
