How not to get bogged down at the start of a project

My name is Nastya, I am the Unit Manager of the international team at Itransition and a project management coach at IT-Academy. For almost 10 years of experience in management, I had the opportunity to work with different customers, products, teams. At the start of my career, I was surprised that, according to PMI statistics, from year to year, more than half of the projects end in failure.

Now I willingly believe this data, because no matter how many IT projects I have started, there has not been a single one so that everything goes perfectly. I also don’t know of a single practicing manager who always went like clockwork (those I met in interviews do not count). Sadly, many difficulties could be easily avoided, or, at least, facilitate the course of events by taking certain steps at the very start of the project.

This article will focus on those practices and artifacts that I pay special attention to at the start of the project. The information will be useful not only for beginners, but also for managers with experience in IT projects: for experienced managers, examples will be more understandable, and beginners, I hope, will be able to avoid such difficulties at the beginning of their careers.

I will talk about both well-known and quite commonplace, but very useful things, and what you will not find in at least the first five google articles on the topic “how to start a project”.

Little talked about, but it would be useful to use

Team Charter or team manifest

Have you ever had the feeling that you are working in a team, but not a team? I have had it many times, unfortunately. The first step towards building a team, I most often choose Team Charter. I really like this tool, as it solves several problems at once. In this case, not only the process of creating the manifest / charter of the team is important, but also the resulting artifact.

First, Team Charter allows you to align context and learn about team roles and project goals. They rarely talk with the team about such things, although it requires very little effort, and the effect of sincere involvement in the work and the absence of unnecessary communication and false expectations can exceed all expectations.

Second, the manifesto establishes clear and transparent rules of the game, which reduces the overall level of anxiety. Starting a new project, like any change, is always stressful for everyone involved due to the large amount of uncertainty. Yes, it is not only the manager who is worried. We do not know how we will be received in the new team, what behavior is encouraged here and what values ​​are followed.

Uncertainty creates psychological stress and fear of error, behind which is fear of rejection. This is a very deep topic, but I would not like to move away from the start of projects. Therefore, I recommend that anyone interested read the works or watch the video by Amy Edmondson, one of the leading researchers on psychological safety in the workplace.

Third, the manifesto shortens the onboarding time for newbies. One way or another, we are not immune from changing team members. In this case, the manifesto will give the newcomer information about which group of people he is in, why and according to what rules this group exists.

Onboarding Guide or Beginner’s Guide

Continuing with the topic of changing team members, it will be very helpful to start creating an onboarding guide for newbies right from the start of the project. At first, it will serve as a description of routine processes (project description, vacation, sick leave, time tracking, team building, manifesto, etc.) for all team members.

And then, when the team gets used to these rules, the guide will become a reliable support for every beginner. Otherwise, you will have to retell all this information by word of mouth, spend a lot of time on this process and face annoying troubles due to the fact that some information is still lost.

Communication plan or communication plan

In the vastness of the global network, you can find a great variety of different communication plan templates, so it would be a little cunning to say that little is said about it. But they usually speak not substantively, but rather too theoretically. I find this tool extremely useful, so I will share how I use it in my practice.

I usually create a page on Confluence called Communication plan where the table is located. Its top line is a timeline – a diagram of the working week or month (depending on the duration of the iterations along which the workflows are built). The next lines are devoted to communication tools, usually meetings and all sorts of reports.

All that remains is to mark on the timeline which of these tools will be used and when. This allows you to see how evenly the meetings are distributed, whether there are piles of meetings and time overruns on communication. The table can be supplemented with various details and links, as well as required and optional participants. The same can be done in a separate Outlook calendar, not everyone is comfortable with posting report reminders in this tool as an event.

Register of legal documents

Everything is simple here: in order not to lose or forget anything important, it is better to store everything in one place at once, be it a folder on Sharepoint or a page on Confluence. It is important to mark the “expiration date” in order to update the required documents in time.

This will avoid the situation when the team has worked for the next month, the client suddenly stopped paying the bills, and the documents for the provision of services are already expired and no one is going to sign them again – the funds have run out.

What many people know but often forget

Contract

What is the starting point for starting a project? In IT service companies, as a rule, the signing of a contract. But for some reason, managers do not consider it necessary to read this very contract. I will try to briefly describe what you can find useful there, in addition to the well-known delivery time and cost:

Deliverables or volume of services supplied

It happens that people don’t look here until the very end of the project – and then they find a lot of interesting things. The scope of delivery, in addition to the code, may include various documentation and additional services. Knowing about such nuances, you can prepare all these artifacts in advance, in a calm mode.

For example, on one of the projects, the delivery set had to include requirements in the form of a specification. But, not paying attention to this, the team worked on the requirements only in the form of a description of Jira tickets. Fortunately, everything ended peacefully and this was enough for the customer, but for this, the manager, together with the business analyst, had to make a lot of efforts.

Assumptions or assumptions

Assumptions are usually formed at the project appraisal stage, but are not always justified, although they affect the project appraisal. On the other hand, assumptions are often the mainstay of the manager’s hope not to stay extreme when things go awry for some external reason. The assumptions make it possible to negotiate with the customer not from the position of justifying, but on an equal footing. On the other hand, assumptions are closely related to risk and give us a head start in dealing with circumstances.

For example, the assumptions indicate that the customer will provide ready-made APIs for front-end development. Accordingly, there is a risk that this assumption will turn out to be wrong. In this case, the team will have to, at a minimum, make additional efforts to integrate with the server side of the application. The task of the manager is to determine how strong the impact on the project of the risk will be, that the assumption will turn out to be erroneous, and to draw up a plan “B”.

Acceptance procedure

Even when the project is going well, the team is happy and the customer worships you, everything can change during the acceptance stage. Believe me, when you disband the team, your backlog will be full of minor bugs, and the customer will refuse to accept the project until everyone has fixed it, you remember this clause of the contract. If the contract does not explicitly indicate the level of quality of the supplied software, be sure to include the item “agree on a testing strategy with the customer” in your checklist at the start of the project.

This clause usually describes the reports that the contractor is obliged to provide to the customer, as well as the procedure for accepting these reports. In this case, I do not recommend acting exclusively “according to the letter of the law” and sleeping peacefully if the customer has not responded to your letter with a problem report within the agreed period. This usually means that there is a risk of “running into” even bigger problems and misunderstanding of the customer in the future, although, according to the agreement, the report is considered accepted.

I have indicated only three points, but the agreement is necessary and important to read in full, thoughtfully! In my practice, there were examples when a manager promised a client a guarantee, guided by his experience with contracts in another company, although it was not spelled out in the current contract. It happened that they replaced team members without observing the terms of the contract, which entailed the righteous anger of the customer. But this could have been easily avoided.

Project charter

I very often heard that the charter is an atavism, nobody needs it and carries no value. But the contract is far from available to the entire team, but an alternative artifact, which contains all the basic information about the project, has not yet been invented. The project charter does not have to be an official document – a neat Confluence page or Wiki with all the necessary links is enough.

Even if you are working as a dedicated team contract, the charter will make you wonder what your stakeholders really want. Such thoughts, supported by concrete actions, transfer you from the category of administrators to managers. In my opinion, any project should have a charter, as a subject of hygiene, as the title of a book.

Kick-off Meeting or Project Initiation Meeting

I would compare kick-off with the first date: how the first one goes depends largely on whether there will be a continuation. Yes, the relationship with the customer is supported by an agreement, but no one is safe from escalation and requests to change the manager. But for some reason, they do not always prepare for kick-off as reverently as for the first date. I won’t talk about the agenda of the meeting, but here’s what I recommend paying attention to:

• Get ready and do the internal kick-off. This will allow you to rehearse a call with a customer, communicate with the team, with pre-sales, collect all possible information and create a list of open questions. As a result, you will be more prepared and less anxious.

• Prepare your presentation. It will greatly facilitate your task as a speaker and will allow all participants in the meeting to more easily grasp the information, to be always in the same context. There are enough tools for this: Microsoft Power Point, Miro, Prezi – a choice for every taste.

• Make sure that everyone on your side has their cameras turned on, the microphone is sound, everyone can be seen clearly, everyone has a proper appearance. Call the client 30 minutes before calling to check everything. Everyone is already accustomed to the conditions of a remote location, so if suddenly a cat or a child appears in the background, it’s not scary. It’s scary if you start behaving inappropriately and yelling at a child or a cat.

• Warn the client about the format of the call. Usually I send the presentation in advance so that he can prepare, and also make additions or edits if necessary.

• Send follow-up and follow-up invitations. If you do not document your agreements, be sure: they will be forgotten or, worse, at the moment of the onset of problems they will not be used in your favor.

I’ve seen projects where there was no internal or external kick-off. I also saw projects where kick-off took place without presentations and high-quality preparation. They did not close, but in addition to a touch of indifference on the part of management, other, more serious problems arose.

For example, it was not revealed that the client is not familiar with the Scrum methodology and simply does not understand the role of the product owner that the manager has “awarded” him. Or, there were critical differences in understanding the level of transparency in development processes, resulting in escalations.

Conclusion

While writing the article, several times I caught myself by the hand so as not to delve into any of the above topics. Although this is far from all that is included in the work of a manager at the beginning of a project. I hope the list is helpful and helps you avoid some of the hassles from the start. All these tools are not a panacea, the main thing is to understand what their use is and why a manager should use them. If you have anything to share on this topic, I’ll be glad to discuss it in the comments!