Starting a project successfully

How a seasoned pro lays the foundations for project success during the first week of a project

14 Sep 2023

The Scott Logic practitioner's guides are designed to be small practical guides for IT professionals. We draw on our collective experience to tackle topics that we don't feel are addressed elsewhere. Our hope is that these little 'value adds' will help you just as much as they have helped us.

This guide is made available under the permissive Creative Commons CC BY-NC-SA 4.0 license

Introduction

Today I am going to explain how an experienced manager can arrive on a project, follow a few simple but key guidelines to create the foundation for project for success, and all within the first week.

It doesn't matter what formal (or informal) process you are using for your project, getting things right in week one is really important. It is full of subtleties, and hard to describe.

Week one often lacks tangible goals beyond 'get settled in' or 'onboarding', and as a result, I don't think people give it the attention it deserves. In almost everything else we do, making a strong first impression is paramount to success, and people recognise the importance of it. So let's do the same with project kick offs, putting the effort in from the start getting it right and paving the way to success.

You don't need to be a pro or even a project manager, anyone can follow this advice and set up their project with strong foundations.

In this guide I'll talk about the key steps that a pro would complete in the first week of a project...and I'll avoid all the complicated jargon.

Meet the Hero(s)

Over the course of their career, a typical project manager starts and finishes numerous projects, spanning a variety of industries. A project doesn't have to be a software delivery project or even a business change. Have you ever planned a surprise party? Have you organised a group trip abroad or project managed a house renovation or extension?

Regardless of what your project is delivering, all require someone to take ownership of the project; to make sure the right things happen at the right time, and by the right people.

And, if you are being brought into a failing project, you can apply the same tips that I'll describe in this guide, to turn your project around during your first week.

Now, some people will turn straight to a project management methodology like Prince2 or SCRUM or the GDS framework. But the tips I want to share with you are things that aren't discussed in your standard delivery approach. These are the little gems that make the real difference but that nobody tells you when you start.

Results

By following the key steps to success, you will ensure that you have:

• earned the trust of key stakeholders,

• have a clear understanding of the current situation

• understand where you need to prioritise your efforts

• have a team who are willing to follow you into battle

• and a prioritised battle plan to take you forward

So, what are these keys? Keep reading to find out how you too can set yourself up for success time after time after time.

Six Keys to Success

Key 1: Stakeholder management

When you land on a new project, or even an existing one, you need to find out pretty quickly who the important people are with regards to your project.

Stakeholders can come in different guises. They can be people who are supplying the money who want confirmation their money is being well spent, they can be passionate people who have grand visions of exactly what they want from your project. They can also be other delivery teams who are dependent on your project delivering well and on time.

Top Tip

How do you keep on top of all those new faces? Simple: keep a log. Take screenshots of any Teams calls or Zoom meetings where people are on camera and store them in a document somewhere. You can really help yourself by adding in notes about each person e.g. Darth Vader, Dark Lord of the Sith, skilled negotiator, highly intelligent, bit narcissistic has a pet droid called C-3PO, clashes with Team Jedi.

Details of hobbies, holidays, pets, kids names will give you things to talk about in one to one conversations later. Over time you will just remember most details but in week one help yourself by taking some notes….but as I remind my children about their social media pages, if you write it down, it will get read.

The sooner you can find out who is important to your project and who your project is important to, the sooner you can start talking to them.

Some stakeholders will hunt you out to make sure that you hear their voice and what is important to them, but other stakeholders prefer that you take the time and effort to work out who they are and to make the first move. It's easy to start engaging with the former but it's usually worth the effort to find out who else you should be talking to. The less obvious stakeholders are often the ones who can tell you important nuggets of information, such as why your project won't work, why they understand the passion of the enthusiastic stakeholders but still have concerns due to elements the enthusiasts are unaware of or unwilling to address. The sooner you know this stuff the sooner you can do something about it.

Top Tip

In your first week, treat everybody as an important stakeholder. You only get one first impression, so don’t accidently dismiss someone because they are not highlighted in the business case as a key person of interest, they could end up being the person who saves your project from failure. If you have befriended them in your first week, they will likely be an ally ready to act quickly when you need them later!

Once you have worked out who your key stakeholders are, you need to make sure you get the most out of your time spent with them. They are likely to be busy people and in your first week you will probably meet more people than you can realistically cope with.

One of the best ways to engage with people in week one is to listen. I was once told that I had been given two ears and one mouth and I should use them in the proportion that had been intended. Despite it being somewhat offensive, it's actually a really good piece of advice for project week one stakeholder management.

Have you ever been in a conversation chatting about something and someone you have never met before starts talking with a voice of authority? Doesn't it just wind you up? The same is true for your stakeholders. They want you to listen, they want you to understand the complexities, the concerns, the time pressures. It's tempting to jump straight into solutionising or talking about when you have solved this problem previously somewhere else. Whilst it's great that you know your stuff, your stakeholder needs to make sure that they have told you everything that is important to them. Listening to them, and asking exploratory, engaging questions is the best show of respect you can give.

Do take the time to listen to not only what people are saying, but also what they are not saying. Do your stakeholders avoid talking about dependencies on a particular team? Does one of your stakeholders keep referring to the fact someone is far too busy. What's really going on? What aren't people telling you. In your first week you are innocent or ignorant of all politics. This puts you in a lovely position to ask questions that you might not get away with later once you become aware of tensions and powerplays, you can always apologise and back off gracefully if you overstep the mark.

However, if you sit in the room just listening you run the risk of being categorised as inactive or ineffective. It's your first week and you do need to make sure that the stakeholders have confidence in you and your ability to deliver this project. Remember that it is two ears and one mouth and not two ears and no mouth. You need your stakeholders to trust you, demonstrating your ability is a great way to do this. Ask intelligent, relevant questions, clarify scope when it's being discussed, you can also fall back on experience and say things like 'I've noticed that you don't do x and y here, is that a deliberate decision?' 'have you thought of trying a,b,c I used it with a previous team and it was very successful. Be careful not to just chuck in buzz words though, only talk about genuine experiences and skills that you have. Do try to demonstrate the value that you will bring to the project.

Another way you can demonstrate your skills is to research the project before joining. If it's a small project in a large government programme of work, then find out as much as you can about the programme. If it's a large project in a small sized business find out about the business, who is the CEO, what is their background, do you have any common associates in your networks. Try to find out as much about the project, the organisation and the people as you can. This will assist in you asking intelligent questions, and also will help you think about which of your skills you might like to demonstrate early on; what is your biggest value add to this situation, highlight it.

Within any organisation there will be politics, power plays and alliances. Try to work out who is pally with whom. You don't need to do anything with this information in the early days, but start working out the politics as early on as you can. There is nothing worse than accidently navigating into a conflict whilst trying to deliver a project, having early visibility of these allegiances allows you to navigate around them and could prevent you from trouble later on down the line. One of the best ways to work out politics is to meet face to face. If it's possible hold as many of your week one meetings on-site or co-located. This allows you to see the body language as well as the facial expressions. Who sits next to who, which people were chatting together over coffee. You can learn so much from the social interactions that are just not present on a video call.

Stakeholders are exactly that, they are people or teams who have a vested stake or interest in your project. You might not be talking to all of them daily. It's good to find out up front how they like to pass and receive information. What are they expecting from you by way of engagement and progress reports. There is nothing too tricky about discovering what works for each of your stakeholders, just simply ask them and then try to implement whatever they have requested. If there are 5 people all wanting an update then produce one update and send it to all of them, or hold one update call. You can be as efficient as you can with how you implement the requests, the important thing is that you listen, acknowledge and act on their requests.

My final and possibly most important piece of advice on stakeholder management is simply to smile. No, that is not some buzz word acronym, it is smile in the literal sense of the word. You've just joined a team, your stakeholders are invested in the project, they are excited by what is about to happen, embrace that. Show your enthusiasm, let people see you are approachable and friendly. Smiling is infectious. People are much more productive and successful when they are happy so start off how you intend to go on, smile.

Key 2: Environment

When you land somewhere new you need to get a good understanding of your environment. Think of your first day on a holiday, you find out where the restaurants are, where reception is, where the pool is, who do I need to talk to get a towel for the beach. You familiarise yourself with your environment so that you can navigate around the new environment effortlessly for the rest of your break.

Starting on a project is no different. You need to rapidly gain as thorough an understanding as possible about the situation you have arrived in. We have discussed the importance of stakeholders. What more simple way to identify some of your stakeholders and understand the hierarchies than asking to see an org chart? Get your hands on an org chart as soon as possible and actually study it. If you can understand who reports into whom early and which departments exist in the organisation you can start building up a picture of how the company works. For example, is there an Service Management Team, if yes then you are likely going to have to deliver a project into an existing working system, if not then you may be trailblazing and have to set up the service management team as part of your project, this could have huge cost and budget implications.

Top Tip

Remember, whilst doing your investigations, be politely tenacious. People are busy. Taking time out of their day to explain the setup of an environment that they are very familiar with is really a bit of an annoyance. People may try to delay having the chat with you, or suggest you talk to somebody else instead. Whilst you can empathise with their perspective you still need to get hold of the info you need. There is no harm in politely reminding someone that you need to have a chat with them. You can also send a meeting invite and ask them to pick a more suitable time. If you need information then you have to make the meeting take place.

As well as people and teams you also need to get a good understanding of the existing products and services, processes and solutions. What already exists, what are you going to have to navigate around or integrate with? Is there a project in flight already responsible for building one of the key dependencies of your project? For example, if you are building software to go on a fruit picking robot, who is building the robot? When is the robot platform going to be ready? When can you first try adding the software to the robot? You need to find out what already exists, have standards been agreed to such as building standards, or design standards.

Business processes are always fun, even the most thorough organisation will have gaps in their documented business processes. As an organisation grows it's processes grow and mature with it. Keeping these process documents and instructions up to date is a thankless task and one that often gets left out making it hard for new starters to gain an understanding of what is already in place and set up. The best way to understand business processes is to talk to the people who follow or implement them. Ask a call centre agent about what they actually do or a banking clerk about why they are conducting certain activities. You won't be able to investigate every step of every process, but you can talk to people about the main processes and a high level overview of who is involved and what happens.

Key 3: Team

Now for me, this is the most important key. No captain is successful without an amazing team working with them. For me the best teams are those where the individuals understand what they are responsible for and also what their teammates are responsible for, they understand the processes they need to follow and the quality that they are expected to work to. These things aren't just magically understood on day one. They need to be discussed and agreed upon.

You need to take time early on to have team sessions where you agree between you who is responsible for what. Think of any sports team, there are clearly defined roles and all players understand who is in which role and responsible for what. The slight difference is that when delivering a project you might not have such clearly defined roles. You might also be in a situation where you have fewer people than you would like, so the missing roles or positions need to be divvied up between the team members you have. Regardless of the situation, never assume that people know what they are responsible for. It removes so much ambiguity and is far more efficient to have a conversation and clarify these things early on in the project. It also helps to prevent conflict later on down the line "but that's not my job, I'm not responsible for that, Steve is".

Another common scenario to find yourself in is where someone else has designed the team that you are working in. There may well be roles or job titles that you are not familiar with. Having the early stage conversations about who is doing what allows you and the other people in the team to ask and gain an understanding of what these unfamiliar roles are going to be focusing on. Chances are if you are unfamiliar with a role title then others in your team are too. Having a role clarification conversation gives everyone in the team a safe environment to ask 'what is it you do?' without sounding stupid.

Week one is a fantastic opportunity to understand the work ethics of the different people in your team. If you set the team a challenge or ask them to complete a task, who steps up to the challenge without hesitation? These people are likely to be the ones that you end up relying on or having in your inner circle. You need to know who has your back. Not everybody comes to work to shine, some people are happy turning up getting the job done and going home. This is perfectly acceptable. But you need to know who these people are so that you don't overload them when delivering under pressure.

Week one is also a good time to work out who in your team is going to need more support. You may have some less experienced people in your team. This may mean that you need to spend more time explaining processes and ways of working initially because they are yet not familiar with standard processes. Everyone has to learn, and it is important that you have patience, but being aware that people may need more of your support and attention early on will enable you to better plan the work and manage potential risk.

It's useful in week one to agree with your team how information is going to flow in and out of the team. Who is going to talk to the senior stakeholders to get direction and feedback on how the team is perceived to be working? Is it ok for each individual to talk to senior stakeholders directly or are the stakeholders incredibly busy and one conversation would be better for them, with the info brought back into the team? Different teams and projects will have different set ups, but it's important that the team members understand how they are to receive key information and share it outwards. Are you having regular 'show and tell' sessions, how often are these to be held? Are you going to have a daily meeting to align on tasks and progress or one longer weekly session? There is no right or wrong answer to meeting frequencies. You need to put in place what works for the team and the people in the organisation, but what is always required is clarification and visibility of what is being set up. People need to understand what is happening when.

It is very tempting in week one to try to do everything yourself. This is never a good idea. You need to empower your team members from day one. People need to start as you mean for them to go on. Give people tasks and actions and get them to report back to you. There is so much to be understood in week one. Having an empowered team will be so much more productive than trying to do everything yourself. It also sets a precedent, that each player in the team is expected to pick up tasks and complete them, this is a team and everybody is expected to join in. It also is a great demonstration of belief in your team members. Nobody likes to be micromanaged, give people the space to work and let them impress you, start this from day one to make your own workload more manageable and less stressful.

Think back to a time when you were part of a successful team. I bet it was a happy team? Happy teams are usually the most effective. People who are happy work better, are more productive, and support each other. Week one if used properly can be so powerful. If you have fun as a team in week one when the pressure is usually less intense it can set the tone for how you will work as a team for the duration of your project. My key message here is try to have fun, be enthusiastic, encourage people to chat and get to know each other. You want to get the team to bond and become a team. Give yourselves a silly team name, not only does this make people feel part of something but it adds a bit of fun and makes searching for your team info easier later on down the line. Imagine searching a large company's folder structure for 'Team 1'. You will probably pull back hundreds of results from decades ago.

What is tricky in the early days of a project is having fun without it being 'forced fun'. We've all been in those meetings with the painful icebreakers, 'which animal do you most resemble' or 'what is your favourite ice cream flavour'. I'm yet to meet anyone who actually enjoys this type of 'fun'. Equally, let's all go for a beer isn't very inclusive for your non-drinking team mates. It is hard to get this right, but that doesn't mean you shouldn't try. Sometimes encouraging natural conversation is sufficient enough to get people communicating. The ultimate aim is to get people communicating, but the more natural you can make this communication, the more successful you will be. The more genuine people can be in your team the stronger the bonds they will form, the stronger the bonds the more fluid the dynamics within the team resulting in a much more successful and productive team.

Key 4: Governance

With any project there is always an element of 'the boring stuff'. You can ignore this for as long as possible in the hope that it goes away or you can tackle it head on. The first approach is just kicking the can down the road. You are always going to have to address it at some point. My advice is to get on top of it in week one.

You need to work out which delivery framework you are going to follow. There are so many different opinions on which project delivery approach is better. My opinion is that it almost doesn't matter. The key to successful delivery is to pick an approach, communicate it out, and get on with it. No project delivery framework is perfect. If you spend too much time at the beginning procrastinating and looking for the perfect solution you will just waste time. Choose the framework or process that you think will be best and start implementing it. When you spot something that doesn't quite work for your situation or environment then adapt to overcome it. Being dogmatic about a process is as bad, if not worse, as having no process at all.

You are going to have to track your project costs. A large proportion of costs are likely to be the cost of the time people are spending on delivering the project. Most projects and companies will require you to complete a timesheet in some form. Get these sorted in week one, make sure the team knows how to complete them and make sure that the necessary time recording codes are in place and available to those who need them. If you set this up in week one you will save yourself a lot of time, effort and grief trying to get time recorded accurately retrospectively.

Applying the same approach to document repositories will also save you pain later down the line. Agree files structures, and document title formats in week one and get people adhering to the rules and your life and those of your team members, will be stress free later. Finding documents 6 months into a project can be a nightmare. Store them correctly from the beginning and you can avoid all the unnecessary pain that most teams suffer during the more pressured phases of the project. Again, the specifics of which rules you want to implement aren't the important thing here. What is important is that you set something up, agree it with all team members and get people using a uniform way of doing things so that you can navigate it later. If you need to tweak it later, so be it, but you are tweaking or changing something that is organised rather than trying to bring order to the chaos that has evolved over the last number of months.

The final element of governance that you need to think about in week one is your escalation process. What are you going to do when you have a problem that you need support from someone else to fix? What will you do if a project you are dependent on is cancelled? It's unlikely that you will need to use the escalation process in the first week but it is important that you set it up so that it is there when you need it. You need to think about escalations up the stakeholder chain of command but if you are a contractor brought in to manage a project you will also need to think about the escalation process within your own company. Who will you talk to if your client is acting unreasonably?

Key 5: Scope

Scope is possibly my favourite key. This is where you get to learn about what you will be working on and delivering. You can ask questions like a small child, 'what does that mean?', 'why?', 'when does that happen?'. You can ask and ask and ask in week one and you have the safety of knowing that there are no silly questions, because you are new to the situation. You can also get away with asking the same question a few times over. People are more easy going during your onboarding and learning period, you should really take advantage of this to gain as much knowledge as you can. It's really important to hear the stakeholder explaining what they understand the scope of the project to be. Having key stakeholders talk through exactly what they want will give you much more clarity on what is expected.

When asking about scope, it is important to get not only the project scope but also the context of how the scope fits into the organisation. You can do this by finding out about the company or programme goals and visions. It is important that you understand the holistic picture of the organisation's ambitions. Having this context will allow you to discover dependencies and also understand higher level priorities.

One of the pitfalls people make when trying to work out the scope of their project is they forget to ask what is out of scope. This is often a much more important question than what is in scope. Finding out what is explicitly out of scope can save you time, effort and budget later. It can also be crucial in managing your stakeholders expectations. There is nothing worse than assuming something critical is out of scope only to see the look on your stakeholders faces later when they realise you aren't planning on delivering it.

Top Tip

You should take the opportunity in week one to ask people to explain acronyms. We all do it, talk in TLAs, but there comes a point on a project where you are expected to be able to join in with the lingo. In week one stop everybody who uses an acronym and ask them what it stands for. Don't forget to write them down somewhere for you to check back against later.

Key 6: To Do List

The final and simplest key is to write a to-do list. During week one there will be so many actions, tasks and things you want to investigate further. You need to write them all down otherwise you WILL forget. You will also take far more actions than you will be able to complete, so write them down and last thing on the Friday afternoon spend 15 minutes prioritising them for your start first-thing on Monday morning. It's a silly little thing to do, but you will thank yourself for it when you sit down on Monday after a weekend off and realise that you were bombarded with so much information during week one that you have not managed to retain it all.

Conclusion

Week one on any project is fast paced, possibly chaotic but certainly a time when you will be taking on more information than you can process. The more successfully you manage the first few days on your project the better positioned you will be to handle the inevitable challenges later on down the line. Do yourself the favour of following the 6 keys to success on your next project, you won't regret it!