Project Methodology For Outsourced Product Development
Product methodology for outsourced software development typically varies across various technology firms. Firms usually adopt different project methodology frameworks based on their customers’ needs. Usually, these are iteration based – either in Agile Product Development Mode, or in Iterative Incremental Prototype Mode based on Rational Unified Process.
In an Agile model, the scope section of the proposal is based on inputs from Product Manager, which gets updated with each iteration, while in the Iterative Incremental approach, sufficient detailing to scope is done based on a prototyping approach.
The steps in the Agile model are incremental right from scoping, design, and development and divided into number of iterations, and scrums. A few basic and common activities form part of the project:
The Project Manager (PM) interacts with the client / client Product Manager to analyze the client requirements. The PM asks for web designs that the client might like to suggest, viz navigation controls in header, footer or alignments of the content (left, right, or centre), any icons to be used like logo, etc. and any desired layouts of templates required.
The inputs from you, the client, set the initial expectations for the Business Analyst from your technology partner, who further works with the user interface designing team to come up with a few suggestions about designs. The designs are shared with you and review meetings are conducted, where relevant feedback from client is obtained. The designs are modified iteratively with client feedbacks till you, the client confirms the final design.
Designers start working on screen layouts of the other pages/screens based on inputs of Project Manager, Business Analyst and your Product Manager. The entire process is iterative and the design gets updated with each meeting. The designers develop UI layouts or mock-ups for the different requirements based on user stories or requirements shared by your Product Manager. The User Interface Design is merged with this Prototype as soon as the designs are confirmed by you.
The Project Manager seeks a formal review meeting with the client to approve the design. This meeting usually includes the Client Product Manager, other senior stakeholders from you such as Senior Managers, the Business owner and the Project Sponsor. In this meeting, the Business Analyst demonstrates each screen of the product to the client by using an online URL, where the design is built. Client inputs are duly incorporated and the updated screens are shared with the customer for final approval of design, or design sign-off.
The design sign-off is an essential milestone for developers from your technology partner to start working on the project. It also means that any change required by you would undergo a process of change management and would further need an estimation and client budget.
The Project Manager keeps you informed verbally as well as in writing about the importance of the acceptance, and that change can be done later with additional budget. You are required to provide a formal email confirming acceptance of design and starting work on the next phase.
Going forward, this design URL would act as the single source of truth for UI design and also get updated as and when any change is done to the design. This also ensures that the shared design is always current.
Once the screen design is signed off, a technical architect is on-boarded on to the project. The technical architect works with the Business Analyst to understand the screen flow and subsequently create a database design for the product.
A third level data normalization should be ensured by the technical architect to avoid any insertion or deletion anomalies. A database design is evolved consisting of tables, field names, data types, data sizes, their relationships, procedures, query statements, functions, views, etc.
The architect ensures that this is also reviewed with a Database Expert at your technology partner. Once the database design is completed, the architect also discusses the database design with any relevant contact from your team if the need be.
Code Structure Design
Thereafter, the technical architect comes up with a blank skeleton of how the code should look. This means, he creates the different file names for code (without the code in there), folders, and the directory structure to be followed.
The technical architect also develops a representative design for the code structure, which could be a simple excel sheet with all the files and folders listed there, the definitions of each module and a small description of each line item and its purpose or guideline.
A work breakdown structure is also formalized at this stage. This details the granular tasks to be performed, modules involved and gives an overview of the resource requirement for the project. With the technical design in place, the technical architect along with the business analyst presents the overall design to the client, records any observation to be addressed, and sets expectations.
Project Plan & Schedule
With work breakdown structure in place, the Project Manager is well placed to develop a Project Plan & Schedule with the resources to be deployed, and plan for additional resources required if any. Risks are noted in a Risk Register and shared with you.
A timeline is estimated based on the work to be done by the assigned resource and agreed with the client. The project manager ensures to inform all the relevant stakeholders including the team and assign responsibilities. The project is formally kicked off for implementation.
Project Work Environment
The work environment of project team is designed to improve communication and accountability within the team. A few highlights include:
- Automation of tasks and scheduling using Zapier tool.
- Visibility of project information using collaborating dashboards such as Trello, reminder for tasks to be done set automatically for the team.
- Daily demos and discussions or scrums to ensure that the tasks assigned are completed in time.
Each module to be developed typically undergoes these steps:
- Modular Coding – The coding is done starting from the first module abiding by the code structure, the coding standards, guidelines and rules set.
- Unit Testing – Programmers are required to unit test their work to avoid human errors.
- Code Review & Certification – Once the programmers are satisfied with their work, the Technical Architect does a walkthrough of the code and checks whether the code of the developers has followed the rules, the best practices and the coding standards laid out or specific guidelines of the company. Based on the review comments, the developers rework on the code and share the final draft to the Technical Architect for approval. The Technical Architect formally signs off the code and shares the details in an email to the Project Manager, and a copy to the client stakeholders (like Product Manager or client technical managers) and the Business Analyst.
- Black Box Testing – Here, the QA Analyst is asked to test the features in the new module as well as test the regression so as to ensure that the new programming does not disturb the old modules. The errors reported by QA Analyst are to be corrected by the development team. When the QA Analyst is satisfied that the features are developed as per requirements, he / she sends an email to the project manager, business analyst and the client confirming that the features meet the criteria set.
- Module Approval – The Business Analyst does a demonstration of the features of the module on a staging or demo URL to the Project Manager, and relevant team members. If satisfied ( may be with a few changes), the Project Manager writes an email to client with copies to Business Analyst, QA Analyst, Technical Architect, Business Development Manager, and stakeholders from client side, stating that the module is now ready for validation.
- Client Validation – The client validates the features of the module and shares feedback. After necessary corrections, the client confirms that the module validates the features required.
With all the modules completed, the Quality / QC team does a complete testing of the functionality based on test specifications written. The QC team records all errors, for which development team provides fixes. The QC team further reviews these fixes, and certifies them. All critical issues need to be resolved before the QC team can certify the overall product. A list of open issues is shared by the QC team before their certification.
On QC certification, the business analyst makes a demonstration of the product developed to the project manager. When satisfied with the functionality and working, the project manager informs you that the project is ready for final demonstration.
The Business Analyst conducts a demonstration to client seeking approval, and records any enhancements or suggestions of changes in scope or design from you. If there are critical observations to be addressed, such observations are corrected by the development team. You can further request for moving the project build to their live server.
The build is moved to live server by the deployment team. A Beta Testing stage for 1-2 months is initiated where you are asked to have mock clients or test clients to test the application and report issues.
Issues within project scope are corrected without additional costs to the client by your technology partner team. Anything which does not meet the design sign off criteria, or approved additional changes accommodated, is referred to as an issue or bug at this stage.
At the end of Beta Testing, the expectation is to have a robust working software without errors. With the end of Beta Testing, the project is deemed to be completed and the Project Manager seeks a Project sign off from client.
Your team signs off the project and records additional changes or observations which are to be done as part of future release. Additional changes, if any are to be scoped separately and can be considered in the next release repeating the processes mentioned above.
If there are changes in scope while executing the project after design sign-off, those changes are to be documented by you and shared with your technology partner, as change requirements.
In that case, a process of Change Management is initiated by your technology partner. The changes are estimated – a thorough impact analysis is carried out for effects of the change, the effort and schedule impact by the team.
The changes with their effort and schedule impacts and the estimated costs for implementation are included in Change Request Forms by project team members. The Change Request Forms require approvals by the Project Manager, who in turn forwards the same to the Client Manager seeking approval. On successful approval, such changes are added to the scope of work.