My colleagues from Marketing and I are upgrading Itransition’s site, writing new pages, updating old ones. Then we send the results of our work to production: designers make layouts, developers build the backend, and testers find bugs and return code to be rewritten. And each of these professionals has their own task, deadline and a unique vision of what the new site should be like.
By company standards this is a small project, but there are still many players involved. Moreover, sometimes these players are also customers. For example, if I am responsible for a web page, simply sending the content to designers won’t cut it. I will need to get them to prepare layouts and help me with images, check how layouts turn out and correct bugs the testers find. Managing such projects and delivering them on time is quite a challenge.
NDA restrictions won’t let me spill the details of real projects, so let me describe a collective image of a multi-vendor project. I imagined a project, where all possible management mistakes we faced in our experience as an outsourcing software development company, were made. Here is a list of them along with the tips on how to do it right so you don’t fall into the same trap we did.
What happened: Imagine a startup with a bright idea of a new IoT device. The CMO found a niche market. The CEO blessed the idea, but said: “You guys do it the way you want to, and report to me.” The CFO estimated the necessary investments, and said, in horror: “Over my dead body.” The VP of Delivery said nothing, but his feelings were hurt. In essence, each player obsessed over their part of the deal, with no one taking responsibility for the final decisions and instructions for designers, developers and testers. The project was put on hold.
What to do: from the start, figure out who is involved in the project and what their roles are, who the main decision-makers are and what their process looks like. Whenever possible, select a project leader, who is ideally a single entry/exit point of all project activities from the company. This should be someone who knows the product inside and out, and has the time for endless meetings and TOR preparation.
You can argue about little things forever, but everyone will benefit if the VP of Engineering volunteers to take on the responsibility for all project decisions. He’ll say: “Guys, I know you’re all pros and I will listen to all of you with great pleasure. But let me be the one to choose ideas for implementation and be responsible for the result. Let’s meet every two weeks: I’ll tell you about project progress, collect your feedback, filter it and pass it on to contractors. Is Monday good for everyone?” And the project will take off.
What happened: the device prototype was ordered in a factory in China, the UX and frontend – in Belarus, the backend – in the US, the testing – in Canada. Backend development started immediately after ordering the prototype, but choosing frontend developers and testers took a criminally long time. As a result, the backend and the device itself were ready, but the frontend guys had no clue about that fact, while testers annoyed us with questions like: “Dude, what’s the deal with testing?” Vendors were out of work, and managers did not understand the status of the project.
What to do: divide the project into 7-14 day phases. Equip vendors with a list of what needs to be done by the end of each phase. To avoid confusion, at Itransition we usually draw all the phases on a Gantt chart, but with a little trick.
The standard diagram lists tasks in lines, and time in columns. If on a project for different parts of the product you have to repeat the same tasks, the chart will be very long. For example, each new device feature follows the same pattern:
If you write the repeated steps for each part of the product in columns, the chart will be much shorter. And everyone will be able to see, for example, what developers are doing at this stage:
What happened: For the interface to go live, the API should have transmitted data from the database to the frontend. Since the backend team failed to meet deadlines, the project ended up neither an API nor a database. Without the API passing on data, the interface didn’t go live. The frontend developers and testers remained idle, and managers learned about the problem when it was far too late.
What to do: set up programs for task scheduling and document storage. We usually use Jira and Confluence, but any other issue tracking solution will do.
To monitor whether everything is going according to plan, you should schedule regular Skype calls with vendors. Before each call, the project leader – VP of Engineering, in our example – should write the meeting agenda and ensure that the time slot suits all the participants. Breaking a sweat to pick a convenient time for both China and Canada is normal, but at least vendors won’t have to figure out how and when to report that they are lagging on something. VP of Engineering will benefit from regular updates on every aspect of the project.
During these calls discuss the readiness of interdependent features and create a plan B in case something goes wrong. Make sure that you go into detail about possible risk factors, their warning signs and actions to address these risks with each vendor individually. As a result of these discussions, you can adjust the plan or give vendors another task.
What happened: the backend team launched the API and prepared the databases, with everything ready to be tested. At this point it came to light that Canadian testers are not able to work with foreign legal entities, and lawyers aren’t happy with the contract itself. The project came to a halt while lawyers spent resources on polishing their wording and emailing each other back and forth.
What to do: reserve time for risks. On any project something always goes wrong: a key player misses a deadline, lawyers bicker, the payment doesn’t go through, and the designer goes to Maui.
In order to meet product release deadlines, it’s wise to reserve time for risks before the work starts. The meeting with testers should have happened before the backend was ready. Everything should have been discussed without lawyers, so all they would have to do is choose the wording and prepare the documents. Managers would have time to check and correct the whole thing, testers would start their part, and the product would have been released on time.
Of course this doesn’t solve all project problems. No one can predict if the senior developer will catch a nasty flu right before the release. Vendors must have a plan for such emergencies. When something goes wrong, they already need to have a roadmap of what to do.
What happened: when half of the backend was ready, it turned out that even though the device was great, for some reason the data was sent to the backend using FTP, and not TCP, as was agreed. Half of the backend had already been written to fit TCP, and FTP support was nowhere to be found. The whole thing had to be rewritten, and we had to press pause on the project.
What to do: record everything vendors say during call meetings. The perfect scenario is to have everyone in the same room and consult one another before implementing anything. But the world is not perfect, and when vendors do agree on some technical issues, just write it all down.
Without documentation each party will do as they see fit. In our example, the backend guys used TCP, because it was easier and more logical. The hardware team preferred FTP, because otherwise they would not have been able to create that kind of device. The project leader should always take care of bringing the two parties together, protocol the solution and make sure everyone works in accordance with documentation. It’s expensive to document everything, but without vital agreements on paper, the project is doomed to struggle.