The previous two articles in our dedicated series about the mechanics of IT consulting walked you through the first two out of three steps in launching a project with IT vendors:
- Presales
- Business analysis
- Project start
During the pre-sale and analysis phases, you and the vendor were making plans and discussing potential scenarios. Now, everything that you have agreed on goes into production and to the programmers and testers who will implement it. Let’s go back to the vehicle analogy from the last article and say you have chosen to build an airplane. In the previous phase of the project, you sat in a design office reviewing computer models. 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, plan work, and introduce you to the team. An important responsibility on your part is checking that the project has started off correctly and is going in the right direction. For you to not miss anything important and avoid IT outsourcing risks, it’s crucial that you understand which project aspects depend on you and how to check the work of the vendor at this stage.
IT project implementation plan: get to know the team
The first thing you need to do is to meet the people who will implement your ‘airplane’. A good team can deliver the exact type of plane you need and have planned for.
The project will look completely different depending on whether your plane is a passenger plane, a military plane, or an orbital one. The project manager on the vendor side selects a team while keeping the 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 the employee has already done something similar. They should also consider how interested he or she is in working on something like that again.
At the introductory meeting, the project manager will present the team’s backbone to you and will explain to all the participants who will have which roles and responsibilities on the project. In turn, you should ask questions about the experience and goals of the team members. It’s important to ask the right kind of questions at this stage.
| Less productive | More productive |
|---|---|
| How many years of experience in airplane construction do you have? | What are the three most important lessons you’ve learned from your previous ‘airplane’ projects? |
| What percentage of rivets is designed with hidden heads? | What experience do you want to gain on the current airplane project? |
Make sure your team consists of motivated people
IT project communication plan: tell the team about your project
So, the vendor has gathered the team, and at this stage there is a lot to talk about. The team members need to start somewhere. An experienced and well-equipped team will communicate with each other and build processes around the values and long-term project 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. It also helps to 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 of the project, the better project participants understand who they work for. And the better the team understands the goals of the end-users and their expectations, the more effective the team will be from the very beginning.
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 and inspire them, but stay honest because at this stage a successful launch and the subsequent project depend on you.
Elon Musk’s goal to build and launch Starship is probably the most well-known project of this type. There’s no doubt that a lot of clear, concise and honest communication is vital for a venture of this magnitude. All team members need to constantly make sure that they are on the same page as the rest of the team in order to keep software development risks to the minimum.
Inspire the team members, but be honest
IT project risk management plan: discuss risky scenarios
The project may require completing of the tasks that nobody has ever accomplished, and, therefore, it cannot be guaranteed that the budget and time estimates are 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, it’s impossible for the project to be implemented or stay profitable within the budget, then the manager should stop as soon as possible so you don’t lose money. Therefore, before the start of the project, the team should further research the riskiest scenarios from the list of assumptions. The team will need your help with this.
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 an 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 soon as possible, and 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 till 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
IT project plan management: 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. At the start of the project, agree on who to go to when issues arise and what forms and channels of communication are best. This will save you time and effort and minimize any misunderstanding.
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 to make sure project decisions are viable. |
| Interim demos | Help to obtain valuable feedback from the client’s stakeholders, which can then 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 planned 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
IT project plan organization: finalize the calendar
Depending on the requirements and the cooperation model, project plans turn out to be different: sometimes a brief description, sometimes a detailed Gantt chart.
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 each milestone and in what form it will show up.
You can also do this: by milestone 1 we will get 18 pages in .PSD format, write 5,000 lines of code, and make 25 commits.
Is this milestone target-specific enough? Yes. Is it measurable? Yes. Does it help us understand how the project is moving toward success? No.
Let’s quickly look at a history lesson. When the British were colonizing India, snake bites were a frequent issue. 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: on this date, we released the first system prototype, which allows us to do this and that.
Now, let’s go back to the airplane project and give some examples of target-specific, measurable, and success-driven milestones. 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 often to take a good look at the overall picture.
The main success metric is a working product.
What’s next
Next, you need to work using the agreements reached and the process you have chosen as your guide.
With flexible project organization, you will have to constantly tweak the product, communicate with the vendor, and plan iterations. You may need to fully engage some employees of your company, the product owner, and business experts to check the risk scenarios during the first iteration.
If you choose the Waterfall method for project management, you won’t have to be with the team on a daily basis. But it may turn out that you will need to wait for two months to reach a certain milestone and see any results. You will have to be comfortable with stepping into the darkness, where, after the project starts, 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. But you should be sure to 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 in the first place, keep yourself up to date with the progress, and stay in touch with the vendor. Good luck!
