13 things to do before you start your business software project

Project initiation is the first active stage of your project (aka the mobilisation or planning stage), and the time to lay the groundwork for the success of the rest of your project.

By the end of this phase, every person who’s going to touch the project should know what’s expected of them and have a good grasp of the required outcomes for the business.

This all takes time. For a small to medium implementation project we suggest you allow six to eight weeks, but obviously it will vary depending on the size and scope of the project.

So, where do you start?

You probably started thinking about the ‘who’ of the project during the selection and sales process. If not, that’s your first priority.

Your get-the-ball-rolling list:
1. Identify the roles you need to fill, and the right people to fill them.
2. Make sure they are available (i.e. not committed to other operational duties or going on leave).
3. Onboard all team members, ensuring they understand their project roles and responsibilities, before the end of the initiation phase.

The contracts you signed to get the ball rolling include outlines for the specifics of the project including scope, time, cost, approach, and objectives, as well as your responsibilities and those of your technology partner.

Your what-to-do-next list:
1. Make sure everyone in your team understands the information which impacts their role in the project.
2. Introduce your team to your partner’s team. Get to know one another’s capabilities over a formal or informal kick-off meeting. Establishing personal relationships will before embarking on the project will facilitate better communication and help everything run more smoothly.
3. Organise individual meetings between key team members to build comfortable, robust and transparent relationships. An hour of relationship building can go a long way to avoiding minor upsets during times of stress and potentially major conflicts further down the track. Here are some examples of key relationships, and who should get to know who:

• Project Executive level – e.g. Project Sponsor to Senior Supplier
• Client Project Manager and Vendor Project Manager
• Client Project Owner and Vendor Solution Architect / Lead Consultant
• Client Subject Matter Experts and Vendor Consultants
• Client Technical Representative and Vendor Technical Lead
• Client Change Manager and Vendor Project Manager and Senior Supplier

Organisational Change Management (OCM) is the framework for managing the effects of change the project will have on your business. A lack of investment in OCM can seriously undermine the success of your project. However, a good technology partner can help you create your OCM plan by training your change manager, and by supporting your OCM initiatives during the project.

Your it’s-never-too-late-to-change list:
1. Do it now! If you haven’t started yet, then project initiation signals your OCM planning and initiatives should start.
2. Make sure that by the end of initiation you understand how your people feel about the project and that their expectations are aligned. Assess the impact of change on your people and have an OCM plan at the ready to reduce resistance and bolster adoption.
3. Make sure your partner’s project team understands how they can support you. A good partner will be able to assist you with ideas to that take your change management beyond training initiatives.

The rules of the game, so to speak. Project governance provides project oversight and support to the project teams, including defining delegated limits of authority, decision-making procedures, and establishes an agreed process for escalation of issues or approvals. It keeps your project running smoothly, to budget and on time.

Your project governance should be clearly laid out by the time you finish initiation.

Your get-it-right list:
1. Appoint and introduce your project governance team, including steering group members from both sides. 
2. Clarify and agree project steering group roles and responsibilities.
3. Set up an agreed cadence for steering meetings and decide how long they should be. (And send out calendar invitations to lock in meetings). 
4. Reach an agreement on the reporting formats and responsibilities of the steering group.
5. Delegate authority for document signatures (functional and fiscal).

Now’s the time to complete a full project risk assessment.

Your I-don’t-like-risk list:
1. Identify and assess project risks (including people and OCM). 
2. Put risk mitigation and management plans in place against all risks.
3. Share risk assessment and mitigation plans with the project governance team for their input and oversight.

Creating a project schedule or project plan is a key deliverable from the initiation phase. And don’t forget to consider that there may be several parties who are each developing their own individual plans.

Your plan-to-succeed list:
1. Make sure you have time to consolidate individual plans. Aligning dependencies and resources against a master schedule can require discussion - and compromise. 
2. Commit to getting your initial planning going as early as possible.
3. Ensure all parties meet regularly during the process to progress to a consolidated plan.

We’ve all heard how too many chefs can spoil the broth. Likewise, with a technology project. The number of vendors involved in a project can impact the complexity of managing it. Without clarity of who is doing what, it’s difficult to hold anyone accountable for outcomes.

Your round-em-up-sort-em-out list:
1. Ensure you have a Responsible, Accountable, Consulted, and Informed (RACI) matrix in place and agreed between all parties. 
2. Make sure everyone reads and understands the deliverables you expect from them, and by when.

If you don’t have a clear and agreed line of communication and collaboration from the outset of the project, you will undermine every other initiative you’ve put in place!

Your tell-it-like-it-is list:
1. Decide who will own and manage project documentations, and who can contribute.
2. Choose how and where you’ll store your documentation (for example Teams or SharePoint). 
3. Make sure everyone knows where to find documents, and how to use the tools provided to edit and upload files, and to collaborate effectively (version control!) 
4. Identify and clarify the use of any additional tools that the project team need to use to manage the project, such as JIRA or DevOps. Agree on use processes and provide training.

Phew. You can relax on this one somewhat, as most vendors will have a set of artefacts that can be used. But there will still be discussion required to ensure that the formats work for everyone and that ownership and update frequencies are agreed.

Project management artefacts include project registers (think risk and issues registers, and change and decision registers etc.), and project status and project steering committee reports.

Project charters outline project roles, responsibilities, goals and stakeholders for the project, as well as providing specific definition for the project manager and how the project will be run. It’s quite common for these items to be clarified prior to contract signing either in a charter, or through a combination of business case, scope, and statement of work documents.

If you haven’t already created a charter or covered these items through your contractual documents, then initiation is the time to get going. It’s important to work with your partners on this as your existing contracts will likely have some assumptions already in place contractually.

Your (mercifully short) to-do list:
1. If you do need a project charter, complete and sign it off before moving to the next stage of your project.

Preparation is everything. You can equip your core project team to participate in requirements and design workshops by providing them with an understanding of your solution’s out-of-the-box capabilities.

Your short here’s-how-to-do-it list:
1. Seek out some foundation or familiarisation training for your team during initiation. This may be online product training, overview, or familiarisation training from your partner, or potentially even YouTube videos.

Ill-prepared data is one of the most common reasons for a project delay. It’s all too easy to underestimate the effort required to extract it or knock it into usable shape (or both!).

Your do-it-as-early-as-possible list:
1. Start as early as possible deciding how you will extract, cleanse, and prepare your data. 
2. Do some test extracts to help get familiar with how you will get your data out. It can sometimes be more difficult than expected. That moment of realisation can endanger the project go-live date if left too late.
3. Identify who will be responsible for cleansing. Do plan to use internal resources for data cleansing as they will be the only ones who will be familiar enough with the data to know if it is correct, and make the business decisions around the data. 
4. If you have the option to use an experienced third party, it is best to do that for assistance with technical extraction and oversight of the process.

Well, we could have made this number one, but that would’ve been a bit presumptive!

We know it seems like there’s a lot to do. Maybe you’re already seasoned pros at the software project implementation game. In that case, give us a call so we can high five you and wish you all the best! However, if you’re new to this type of project, we’re here for you. With over 900 customers, many of whom have undertaken multiple projects with us, you can trust us to provide you with the benefit of our vast experience and knowledge.

Our can-do-will-do list:
1. Help you deliver a successful, low risk project with great business outcomes. 
2. Make you happy.