Jul 7, 2019
Project Owl — a Post-Mortem
Each project is a unique story, and this project was definitely a unique story for our team at Lussa Teknologi. This project started as “hey, why don’t we try…” project (which led to quite a fuck-ups), and ended up producing several of our team’s best practices which is still relevant nowadays.
The project arrived in similar fashion with other projects: a software development firm score a deal with a big client, and outsource some of the development work to our team. In this story, we will define the actors as follow: Users as the Big Client (and their reps), and Client as the software development firm who outsourced the works to Lussa.
The project objectives went like this: the users had an ERP system created from scratch by the client. To enable more flexible access, the User wanted to create the mobile app version of the system. Lussa got the project to mobile-ify the ERP modules into an app.
We used a hybrid approach, one codebase (with small amount of platform specific modification) for Android and iOS platform. Also, in this project, we tried to experiment on several things:
- Assigned a dedicated QA Developer at the start of project
- Filled up some roles (Project Manager, Designer, and Developer) with freelancers, and keeping the internal team to Product Owner, Lead Developer, and QA Developer (spoiler alert: the combination didn’t work)
- Designed Continuous Deployment System for the development pipeline
This Post Mortem will be divided into three parts: What didn’t work, what worked, and key learning.
One disclaimer, this will be written from Project Manager view (mine). So there are minimal technical aspects and more on project management aspects.
What didn’t Work
- Not creating Proof of Concept before starting the project. Some of the most time-consuming key activities could be addressed earlier, such as the fact that the code from the customer had no documentation, the existence of unique methods to access internal data, and non-availability of publishing accounts (Google and Apple Developer Accounts).
- Not defining project output in the beginning due to short time for contract negotiation. The `specification` agreed on in the beginning of the project was more or less “convert this module as mobile app” which didn’t put into account the difference between mobile and desktop experience and technical constraints. This extended to other mistakes, which is creating contract before deciding on specifications.
- Not performing risk analysis in the beginning. We had no risk management plan if the external team members did not perform up to standards, if client requests large amount of detailed revision and changes, nor if project is delayed due to bottlenecks in the development process (can be from User’s side, Client’s side, even from our side).
- Not providing clear control mechanism for team members. We didn’t define parameters / key outputs nor setting standard for team members. We also delayed the termination of the team member with bad performance for far too long despite early red flags from said person.
- Not creating design guideline. This resulted in design inconsistency across modules created by multiple person. The designer also didn’t meet directly with the Users which further undermined the design process.
- Divide the workload into API and apps, or to simplify, “front end and back end”. This created bottleneck because front end developers can only work after API/back end developers finished the API.
- Not creating and enforcing daily reporting mechanism for team members. This resulted in team member not providing constant progress which made it difficult to monitor the schedule slip, especially since the QA team had to work on large amount of code at once due to last-minute work submission.
- Relying on Client’s specification instead of discussing directly with the Users. Fortunately, we learned from it and specification for third and fourth phase of the project (we divided the time frame into sprints) are discussed with client. Previous specification omitted many things, and did not cover hidden specifications which resulted in unclear work output.
What Worked Well
- Assigned a dedicated QA Developer at the start of the project. The lead QA was able to have whole understanding of the application and can act as main reference for other team members.
- Creating a continuous deployment system. This shorten the deployment process by a long shot and enable developers to focus more on coding instead of managing deployment process.
- Terminating non-performing team members (even though it was not done immediately). Not limited to freelancers, we should also consider to reassign internal team member who performed poorly to other task that better suit the person. But this should only be done if we provide them with clear targets and resources to finish their assignments.
- Address the specification mismatch directly with the user. Our customer provided second-hand information which didn’t convey all the user’s requirements well.
- Staying at Jakarta the night before morning meeting. This made the team more refreshed for the meeting and eliminated the risk of coming late for the meeting (which actually happened once with one of the team member overslept and missed the entire meeting).
Key Learning
- Don’t rush to deal the project. Never start a project without clear output and specification. At minimum, allocate time to perform Proof of Concept for the critical parts of the project. E.g. publishing, access of restricted resources, and external code review.
- Discuss specification with the User, not the Client. Especially if our user is knowledgeable and helpful, and our Client has multiple focus (e.g. multiple projects). These type of User must be engaged early because their involvement can greatly help the development process.
- Designer should have capacity for front end development. Designer should be required to provide mock-up, design assets (including ligature for icon pack and vector images), design guidelines, and UI components. This way they can provide maximum value and all pages/modules can have consistent design (Designer should create a design system).
- Always make written contract with freelancers. This way both parties can clearly define their rights and responsibilities. This also forces our team to create a detailed specification to monitor the freelancer’s work.
- Developers should be responsible for a single module. Instead of making them responsible for only API/front end, they should be responsible for delivering a whole module to reduce bottlenecks. This will only work if we define shared components (e.g UI components)before creating the modules.
- Consider to budget for accommodation if the customer / user tend to prefer morning meeting. Or cut the development price and add clause in the contract with our Client that we have right to request reimbursement of transportation and accommodation cost for every out of town meeting.
- Keep 2 versions of the final app, one use data in development environment, and one in production environment. This way, we can do bug fix on the development app, and the client & user can both check for bug fix while keep using the stable app online.
The project was delayed by 3 months, mostly because of bottlenecks, unclear specification, and non-performing team member. We spent 2 months in the beginning by being idle.
After we redesign the project management process and change the team composition, we get better at delivering progress. The problem still persists in bottleneck (because front end must wait for API to be finished), but overall we can better manage client expectations.
