In Persizt, we have been working on numerous different projects of varying scales and technology platforms. Depending on project scope and size, some of the bigger projects need detail planning and project management.
In this article, we will discuss standard project management and development methodology that we adhere to ensure a product of highest quality while meeting the project budget and deadline.
A project usually starts from some forms of enquiries and we will initiate some discussion with the client.
For certain project, client has detail requirement spec out. They already have screen design completed and done by professional graphic designer. Even so, after studying the requirement and design, we usually will discuss face-to-face with client to ensure we truly understand the business requirement and problem to solve. This is to make sure we are solving the correct problem using the correct solution, instead of blindly following the flow from client and facing serious problem of developing the wrong product down the road. Sometime, we might counter-propose a different flow, design or implementation to client.
Project Cost, Schedule and Quotation Preparation
We usually prepare a first rough quotation budget to client to sync up our expectation before engaging in a more detailed discussion and firm requirement specification discussion.
To estimate the cost, we perform both bottom up and top down schedules and try to achieve a balance between them. If the client has a hard deadline, we will see how to schedule reasonable work in that schedule and discuss with the development team. Also, we breakdown requirement into detail to prepare a work breakdown structure (WBS). Adding up work day or hour required for each task would provide a total man-day/hour needed for the project to accurately estimate a project cost for client.
We will also perform a simulation of project resource allocation for the project to determine if we have the bandwidth and resources to complete the client project in the designated deadline. Depending on project complexity and technology platform used, we might assign a mixture of senior and/or junior engineers to the project. One thing to note is that, adding more people to a project would not necessarily guarantee a proportionate reduction of time due to the overhead of communication channel. This is clearly illustrated in the great software engineering masterpiece, The Mythical Man-Month.
If project cost is out of client budget, we usually will present the WBS to client and further discuss with them. As we strive to understand the client problem instead of blindly following the entire stack of feature request that they want, we usually would be able to propose alternative solution with lower cost and/or less features. We will propose a version that would still solve the client’s requirement by removing some fancy and unnecessary features. It’s also beneficial to the client for them to deliver a Minimal Viable Product (MVP) to the market first, then study the market response, feedback and steer the product accordingly. This would be better than investing a huge amount of budget and several man-months into a single product without getting any feedback.
In addition, we usually will propose the entire product to be broken down into several milestones with clearly-defined schedule and milestones. We practice agile development methodology in our development phase. Agile software development is set of software development methods that focus on adapting changes to to requirement flexibly in software development phase. In Persizt, we encourage frequent and face-to-face communication with the client and would greatly welcome a product owner appointed from client and communicate frequently with our project manager.
We practice short development cycle (usually a few weeks up to 1 month tops). i.e. We architect and design our develop workflow to break down into several short period (up to 1 month), while being able to develop and present a workable and testable work-in-progress product for the client to test and feedback. A clear milestone deliverable and schedule will be defined. By the milestone delivery deadline, client will be able to test the product (website, apps or system) available in our test server. Certain test data will also be made available so that client can perform testing efficiently.
Through early milestone tests performed by client, they would be able to provide early feedback and requirement changes in early development stage so that the cost of change is low. Also, this would provide reassurance to client and both sides do not need to take high risk commitment (e.g. Client do not have to pay a large portion of project cost without seeing any thing being developed until the end of project development life cycle)
We also adopt other agile development practices such as code review, automated testing, continuous integration, code-refactoring etc.
We provide and handle interface design for the product as well. We usually start off by designing the flow in a series of wireframe mockup. We use Balsamiq Mockup extensively. The wireframe mockup is very rudimentary, as if sketching in restaurant napkin, intentionally. This is to help all parties to focus on content and interaction, not graphic design detail. This helps the design discussion iterates more frequently and discovers any user flow defect early.
Once the user flow and general design are approved, we will prepare a more detailed design. It would be prepared in Microsoft Powerpoint or Adobe Photoshop for discussion on graphic and theme design used.
With the detail design flow nailed down, we will also furnish a detailed requirement specification to client. The WBS should also be updated accordingly as well. With that, work would be assigned to engineers and development commences. We usually prepare our development schedule and WBS in Microsoft Project or Omniplan.
During the development, task status in project plan would be updated accordingly as the work progresses. Client would be welcome to view and check the real-time status themselves too.
Change is something inevitable in the most software projects. Things change in business environment. What’s more critical is how we manage it and keep the project stays on track and hopefully does not steer away from original timeline and budget drastically. Change request is usually submitted by client, formally or informally. We would appreciate as much detail as possible for the change requested.
In an outsourcing environment, we might not be in the position to question the validity or priority of a change, however, we usually will discuss and evaluate the change request with client. Sometime, when associate with a cost for the change, client might then reconsider the priority of the change.
From development standpoint, we do adhere to good development and coding practice to incorporate and reduce change cost in our code.
We have been using Asana currently and have previous first hand experience in Fogbugz as well. We track all our incoming bug reports in our bug tracking system, whether reported internally or externally (by client during milestone testing or User Acceptance Test or after product delivery). All reports are being recorded with detail steps to reproduce, priority, due date and assignee. They will be assigned and monitored by our project manager. Once they are fixed, test and pushed into releases, it will be closed and updated accordingly. This would assure accountability and efficient quality control monitoring.
Version Control & Build Management
Version control is the integral part of software configuration management. It is crucial in managing your source code systematically, even if your development team is little as one person. It provides a safety net for engineer to fall back, compare changes, debug on certain versions of source code.
In certain larger projects, we need to maintain several copies of different versions of the program as well. For example, one engineer develops and check-ins into main trunk for the main development task while another one working on fixes for soon-to-be release stabilised build or a patch build. This would prevent risky code that is not tested thoroughly going into build that is going to market soon.
Project Delivery and Testing
When the project is delivered (including milestone delivery), we provide a detailed Test Plan for client to perform testing. Certain test data would be prepared too. The project would be considered completed once it passes complete User Acceptance Test by client. We also provide a warranty period to cover any bugs and issues discovered.
In this article, we discuss project development process and tools used by us. We advocate on systematic project management and best software development practice to ensure we would be able to deliver a quality product within client budget and timeline.