How to Work with IT Vendors. Part 3: Project Start

05.04.2018
7 min.
title

Together with my colleagues from Itransition we have prepared a series of articles about what happens before the start of any IT project and how to behave if you are a client. The tips in this article will work with any IT vendor:

  1. Pre-sale
  2. Analysis
  3. Start of the project

During the pre-sale and analysis phases, you and the vendor were making plans and discussing potential scenarios. Now everything that you have agreed to goes into production, to the programmers and testers who will implement it. If we go back to the airplane analogy from the last article, before, you were sitting in a design office reviewing computer models, and now you are buying materials and visiting manufacturers at the factory.

Vendors do most of the work at this stage: transfer the project to production, pick a team, check the analytics’ assessments, plan work and introduce you to the team. An important responsibility on your part is checking that the project has started right and is going in the right direction. In order for you not to miss anything important, I will tell you what project aspects depend on you and how to check the work of the vendor at this stage.
 

Get to Know the Team

The first thing you need to do is to meet the people who will implement your plans. A good team can deliver a plane exactly like the one you need. 

You will have completely different projects depending on whether your plane is a passenger, a military or an orbital one. So the project manager on the vendor side selects a team keeping your vision, purpose and value of the project in mind. Every expert is important since personal motivation and experience strongly influence the overall result. That’s why when selecting experts for the project team, the manager looks at whether this employee has already done something similar, and how interested he is to work on something like that again.

At the introductory meeting the project manager will present the team’s backbone to you and will explain who will have which role and responsibility on the project to all participants. In turn, you ask questions about the experience and goals of team members.
 

Bad Good
How many years of experience in airplane construction do you have?

What are the three most important lessons you’ve learnt from your previous ‘airplane’ projects?

What percentage of rivets is designed with hidden heads?

What experience do you want to get on the current airplane project?

Make sure your team consists of motivated people

Tell the Team about Your Project

So the vendor has gathered the team, but at the start stage it’s in a full informational vacuum. The team members need to start somewhere: communicate with each other, build processes around values and long-term goals. At this moment, face-to-face communication with the customer, and even better with the potential system end user, helps all members have the correct vision of the project and align the team according to the goals of the project.

Projects where experts are not building a plane but installing 800 000 rivets are rarely a success. The more the team understands the context, the better project participants understand who they work for. And the better the team understands the portrait of the end users and their expectations, the more effective the team will be from the very beginning.

So tell the team about your goals and vision of the project, what you want this project to achieve, what it will give the business and how it will help end users. Light their fire, inspire them, but stay honest because at this stage a successful launch and the subsequent project depend on you. Look at Elon Musk, I’m sure his project under the code name BFR will be great. 
 

Elon Musk about BFR and more
Elon Musk about BFR and more

Inspire the team members, but be honest

Discuss Risky Scenarios with the Team

The project may have tasks that nobody has ever accomplished, and therefore cannot guarantee that the estimate is adequate. During the analysis phase, for example, the expert has suggested that a certain task is realizable, but no one really knows how it will turn out in reality.

If, for some reason, the project is impossible to implement or be profitable within the allocated budget, then the manager should stop it as soon as possible so you don’t lose money. Therefore, before the start of the project, the team should further research the most risky scenarios from the list of assumptions. And here the team needs your help. 

Let’s forget our airplane building example for now and suppose you need reports from your internal ERP system. This task consists of two subtasks: collecting data and building graphics. Everyone knows how to make systems that build graphics and how long it takes. But collecting data from your internal system is unknown territory. Maybe you will be able to set up the import in the right format in a certain number of hours, or maybe you won’t.

This question needs to be researched as early as possible, not simply by discussing it, but by ‘playing’ with your system or setting up a single field download. If the risk proves to be serious and the scenario turns out to be unrealizable, try to waste as few resources as possible. If you leave testing risky scenarios for the end of the project, failure will cost too much.

After analyzing risky scenarios in detail with the team, run a reality check. There are different techniques for this. One of the fastest is Fist of Five voting. Ask the team to show a number of fingers from one to five to indicate how sure they are that the project will be implemented at these times, budgets and conditions. If all members show four out of five fingers on average, then the project can be started. But if you and the analyst have created many scenarios, and the programmers are showing two fingers or even one, you have to take a step back before starting the project. People who will do the real work on the project should be sure they will succeed.
 

Identify unresolvable tasks as early as possible

Agree on Communication Processes

Communication on a project is any exchange of information between any project participants. This includes meetings, calls, emails, etc. Team members constantly have to make lots of decisions that affect not only their work, but also the project as a whole. You will save time and effort and minimize misunderstanding risks if at the start of the project you agree on who to go to when issues arise and what forms and channels of communication are best.

Flow of communication within a project team
Flow of communication within a project team

An example of a communication plan:

Activity Purpose
Regular status meetings

Help the team to report and track their progress on a regular basis (e.g. weekly), while also involving the client into making sure project decisions are viable.

Interim demos

Interim demos of the work-in-progress product will help to obtain valuable feedback from the client’s stakeholders, which then can be used for further product enhancements via change control procedures.

Monthly and/or on-demand management-level meetings

Allow senior stakeholders to stay updated regarding project progress, potential issues, and plan changes. These meetings also provide a good opportunity to discuss administrative items such as relationship status and future engagements.

At the start of the project, agree on who to go to for what issues and what communication channels to use 

Finalize the Calendar Plan

Depending on the requirements and the cooperation model, project plans turn out to be different: sometimes a brief description, sometimes a detailed Gantt chart.

An example of a high-level project calendar plan
An example of a high-level project calendar plan

A good calendar plan requires a clear outline of the main project milestones and a description of measurable project success indicators for each milestone. You should know what will be ready by this milestone and in what form.

You can also do this: by Milestone 1 we will get 18 pages in .PSD format, write 5,000 lines of code, make 25 commits and consume 48 cans of our favorite energy drink.

Is this milestone target-specific enough? Yes. Is it measurable? Yes. Does it help us understand how the project is moving towards success? No. Let’s look at a history lesson. When the British were colonizing India they suffered a lot from snake bites. To cope with this, they introduced an easy KPI, the heads of the killed cobras, for which they paid money. What did the locals do? They began breeding cobras.

The system adapts to the metrics we enter into it. So it pays to be careful with KPI. The only truly reliable metric is a good product. Therefore, it is necessary to focus on that goal, and not only on indirect indicators. For measurable milestone-based project planning, we often use looking-backward press releases: by this date we have released the first system prototype, which allows us to do this and that.

Now let’s go back to the airplane example. By Milestone 1 all necessary aluminum workpieces and engines will be ready. By Milestone 2 the wings and the fuselage will be ready; avionics will be delivered and tested. By Milestone 3 the wings will be attached to the fuselage; avionics and motors will be installed.

The planning process should be as clear as possible, and changes should be obvious to all process participants. Your project manager will most likely be using a modern online tool for up-to-date forecasts. Don’t slack on studying this tool with the manager, whether it is JIRA, FeatureMap, Targetprocess, GanttPRO or something else. And go back to take a good look at the overall picture often. 
 

The main success metric is a working product

What’s Next

Next you need to work guided by the agreements reached, depending on the process you have chosen.

With flexible project organization, you will have to constantly tweak the product, communicate with the vendor, plan iterations—practically live with the team. You may need to fully engage five employees of your company, the product owner and business experts to check the risk scenarios during the first iteration.

If you choose waterfall, you won’t have to be with the team on a daily basis. But it may turn out that you will need to wait two months to reach a certain milestone and see results. You will have to step into the darkness where after the project start you enter an informational vacuum. This doesn’t mean that the vendor is doing nothing. On the contrary, so much work is invisible to you: setting up the environment, selecting frameworks, developing architecture, etc. You need to be patient and not interfere with the vendor’s work. And track the health of the project by metrics, keeping in mind the ‘cobra effect’.

Whichever approach you choose don’t forget why you started it all, keep yourself up to date and stay in touch. Good luck!