9 Short Project Lessons You Need To Know

The world of consulting isn’t complicated, in fact we think it’s quite simple, we are all about delivering positive lasting change. In fact we believe that in this particular field we are experts, it’s what we have carefully honed over the varying years our team has practised this fine art. As much as we do this day-in day-out, you’d be surprised at the number of challenges we repeatedly see when projects throw an interesting curve ball into the field of play. Below are a few life lessons we try and instil into our clients project habits on a regular basis:

1. The Importance of actually gathering requirements

It may sound simple but it is surprising the number of times people wish to launch into a new software solution project without first having defined the requirements of the business. Failing to take the necessary time in this area will only cost you time and money in the long run as at some stage during testing or training, or worse still go-live, an issue will arise and be directly linked back to a missing requirement that could so easily have been avoided had requirements been mapped thoroughly in the first place.

2. Changing too much, too soon

It is common to want to quickly change all the things you can easily spot that are broken. We commend the embracing of change and the ability to spot things that are clearly not efficient or effective, you’d be surprised how many people cant. But it is essential that effective change is delivered efficiently over a period of time and not all at once in a big bang approach. Change is as much about those receiving the change as it is those delivering it. Fail to bring people along on your journey and the change will simply be rejected. Asking people to embrace too much change at once will simply cause confusion and have similarly confusing results leaving you six months down the line with less efficiency and effectiveness and disgruntled employees too.

3. A Process of change needs a change process

It is one thing launching into a big change project but change is as much about the process of delivering change as it is the processes you are trying to improve through that very change project. Installing a new software solution into a business is just one part of delivering a change project, but in order to continually improve that software and to avoid the mistakes that led to the previous software becoming outdated in the first place, it is essential that a process is agreed and bought into for continually feeding ideas into the mix and releasing regular updates to the new solution. On too many occasions we see projects shut down at the point a new solution goes live without a clear plan to neither learn from the lessons of the past nor how to move forward and continue improving.

4. The Importance of stakeholder communication

It sounds such a simple thing especially when so much technology exists today to aid communication. Consider it common courtesy to regularly communicate with those involved in projects and also those not involved. Change is daunting to most people and not knowing what changes are occurring makes it even more daunting. We are continually surprised by the lack of importance placed on communications when actually it is probably the single most important part of a project. Like all of us, when we are kept in the dark we get suspicious, but likewise when we are kept in the know, we can adjust our mindsets accordingly and the process of embracing change occurs.

New call-to-action 5. Putting suppliers in charge of everything

The world of suppliers is a complex one, you need their product so therefore you need their people also. Be careful not to ask too much of them though. A supplier’s job at the end of the day is to launch their product into their customers environment. Their interest in bringing a customer’s employees along on the journey and making the process an engaging and enlightening experience is of less importance. They will have launched this software hundreds of times previously so the excitement of a new client will often fade quickly. It may feel like the right thing to do in placing a supplier in charge of delivering a project but a new software solution should always be owned by the business, never by the supplier. That way the supplier can be held responsible for their part of the deal (ensuring the products works and is launched on time) and the business remains responsible for ensuring the system is fit for purpose and the business is ready to accept the change in solution.

6. Out of the box doesn’t mean you can just switch it on

Don’t you love project jargon? It’s amazing the number of times we hear people refer to the phrase ‘out-of-the-box’ as if it’s almost an excuse for cutting costs. Opting for an out-of-the-box solution is a great way of keeping costs to a bare minimum and can also be a very easy way of keeping requirements simple. But, and this is a big but, the phrase out-of-the-box doesn’t mean you simply stick a CD in your disc drive and 10 minutes later everything is working. Out-of-the-box software still requires configuration all of which requires clear requirements. Entering a project with the understanding that this is “just out-of-the-box” and therefore is quick and easy will only result in the project taking longer and becoming confused. Out of the box software solution projects require a clearly defined project methodology just as much as a heavily bespoked software solution.

7. The Importance of actual project delivery experience

Projects aren’t a small thing, in fact there are multi-million pound businesses built just on delivering projects. With this in mind, and how much is actually at stake when investing in a project to change a significant part of a business, it is important that the right people are placed on a project and that they have the right support structures in place to make everything succeed. We regularly see businesses place people in project roles because they don’t have a role for them right now, they want to give them some experience, it’s just convenient for everyone, but when a project has to be delivered to a set of deadlines and an agreed budget, why take the risk on someone with very limited experience. Most every day people wouldn’t take this approach with a similarly specialist field like fixing a car, plumbing, electrics, but for some reason feel its adequate for a project which costs ten times as much. Don’t be afraid to call on industry experts, even if it is simply to provide a coaching role to support and aid the project delivery of those with less experience. You will find the project is more successful as a result if you use the right people.

8. Making the right support tools a priority: Training

It’s not the tools you have, it’s knowing how to use them. Training is an essential cost if you want to make sure your new tech is fully adopted. The more bespoke the training, to suit the individual, the better the results. It isn’t one size fits all, people have different needs and will use technology differently. Once your users have mastered the system and have the right support tools you will be pleased you invested in developing their skills.

9.There are some project documents you just can’t do without

There are several documents which support effective delivery of any project. We would recommend that you get to grips with the following and make them standard issue for all project delivery teams:

  • Business Case
  • Project Charter
  • Project Initiation Document
  • Project Plan
  • RAID Log

You can find more detail on these documents and their merits in a previous blog post here.

If you would like us to expand on any of these points or talk you through our project lessons, get in touch: EstherM@NineFeetTall.com

From the blog

  • How to choose the right technology for business: An IT Director’s Guide

  • Ghost-bust your projects!

  • Technology Procurement Process: Key Steps and Considerations