I’m going to let you in on a secret, some IT projects don’t work. They are complex, they are expensive, they involve lots of people and even when they do get finished, they often don’t achieve the thing they set out to achieve in the first place.
If I reflect on past projects, there’s always a few things that could have been better and things that would have been less of a problem if they were picked up earlier. The more people that are aware of these things, the greater the chance the project will be a success.
Here are my top 9 things that everyone involved in a project should know (in no particular order):
1. The project might not be successful
Not trying to scare you, but some projects fail. “High-performing organisations successfully complete 89% of their projects, while low performers complete only 36%.” (Source: pmi.org). You significantly improve your chance of a successful project by bringing together the right motivated people. Get the right people, give them freedom to self-organise, and you’re on your way to a successful project.
2. There will be some who don’t want the project to succeed
Call me cynical, but a lot of projects are affected people who don’t want the project to be a success. Obviously no need to go on a witchhunt, but be aware who might have motivations to see the project fail. I have personally been involved with a few projects where this happened and if the person is a key stakeholder, this could be disastrous for the project.
3. User experience design is not just pretty boxes but critical to success
If you want your project to be truly successful (and actually be happily used by people) it needs good user experience design. Gone are the days when the developers decided how best someone interacts with the system (usually what was easiest for them). These days the user experience is paramount and it needs to be, if you want people using your system after the project is delivered. Don’t measure your project success by whether it was delivered on time but measure success against pre-defined metrics (i.e. number of sales), track actual usage (where are people going on the site) and review user experience evaluations.
4. Things Change
“The only constant in life is change” so they say and IT projects are no different. No matter how much we like to think we can control and plan for things up front, what we end up building will not be exactly what we thought it would. The rate of change in business is increasing and businesses need to continually adapt to stay relevant. Estimates will change as well, think of them as a guide not gospel. Don’t overplan and make sure you’re setup to pivot freely with the direction of change. Think smaller, regular changes than a big push and be flexible when it comes to funding and regularly prioritise scope.
5. You can’t come out all guns blazing
With every project it takes time for a new project team to find it’s legs and become high performing – so they will need time. If timelines start to slip, it’s important to be aware, there’s a relationship between the time to deliver, budget, project scope and quality. You cannot concurrently speed up delivery, reduce the budget, increase scope and increase quality (much to every project managers displeasure). A change in one priority will have a detrimental effect in a different area. If you want to deliver earlier, you will either need to increase your budget (to get more resources), or reduce the scope or quality and vice versa.
6. Everyone has different expectations about what the project is trying to achieve
When getting into a project, everyone comes in with different expectations. Be careful to ensure everyone is aligned and working in the same direction. If you are building a car, you don’t want some people trying to build a truck and others building a motorbike. Look to align priorities and expected outcomes at the start of a project by running inceptions.
7. Not everyone is going to be as fully committed as you
Even though this project is your number priority, it doesn’t mean it’s everyone else’s as well. If your project relies on multiple teams and key stakeholders ensure that you have their backing from the start. If the decision makers are not involved, engaged and helping to make the decisions, then you’re going to have problems. 33% of projects fail when they don’t get enough senior management involvement (more info). So if you’re not getting the appropriate buy in right from the start, raise a red flag and get their commitment, otherwise perhaps you need to put this project on ice.
8. Information systems have to evolve
Building an information system is not a one-off activity that can be forgotten about after delivery. It should be considered a journey and won’t be finished with a single deliverable. Information systems will need a bit of TLC from multiple teams in their lifetime and there has to be continual drive to evolve it and keep it relevant. There’s always going to be problems in a system, so having a ‘evolving’ mindset means you’ll be able to more easily add new features or fix bugs.
9. Don’t go too big
The bigger the scope of a project, the more difficult it will be to finish it. As things get bigger there’s a greater chance of things going wrong, higher interdependency between components, increased scope creep and just generally greater complexity. Therefore the bigger the project, the less likely a release will ever see the light of day. Keep things small – make incremental changes and continually roll them out. The earlier you can get something released the better (even if there’s other features that need to be added later). Avoid the big bang approach if you can.
There’s always going to be problems that you need to overcome to have a successful project. I have outlined some of the things I think everyone needs to keep in mind when starting out a new project, as these are some of the things I’ve seen. Now with this information, go forth and build something. Good luck.