fbpx
Project Management | Techinsider Asia -1

Project Management For Software Development: Step-by-Step To A Successful Product

When choosing a development team for your project, what should you pay attention to?

Portfolio? Tech Stack? Domain expertise? All of these answers are correct. But more importantly, the development team should have documented project setup processes and development to ensure transparency for stakeholders. 

Knowing the project lifecycle, core deliverables, and critical roles on the project allow you as a decision-maker to be on the same page with the development team, thus, create more realistic expectations and the final result. 

This article explains the project setup and management processes in detail and each party’s key roles and responsibilities during the project life cycle. We also list key deliverables our clients receive at each stage of project development.

1. Step-by-Step in Software Development Project Management

We apply SDLC (Software Development Life Cycle ) as our methodology of choice for the projects we develop from scratch and existing projects requiring features modernization, software update, and code refactoring. 

The SDLC refers to a methodology with clearly defined processes for the development team.

The development team goes through the following steps of the project lifecycle:  

  • Requirement analysis 
  • Planning process
  • Software design 
  • Architectural design 
  • Software development 
  • Testing process
  • Deployment process

Software Development Life Cycle from a stakeholder’s perspective includes the following phases:  

  • Inception 
  • Project Initiation 
  • Project Development and Quality Assurance 
  • Final Project Demonstration Session
  • Technical Support

Each of these phases requires the cooperation of stakeholders with different team members. Let’s take a look at each stage of software development in more detail.

Phase 1. Engagement 

The engagement phase is the first step toward project development. It takes four weeks for our development team to determine user roles, ways users interact with the application (user stories), and project usage scenarios. 

Each week of the engagement phase has its goals and deliverables:

Week 1. Understanding

We suggest relevant technologies, dig deeper into your business and highlight the main business challenges you want to overcome with the project. 

We achieve these goals by:

  • Defining your business goals 
  • Discussing business needs
  • Checking out the current product infrastructure 
  • Running requirement elicitation session
  • Limiting potential opportunities for further cooperation 

Week 2. Definition

We shape the project vision and create a list of features for the first project version with basic features, i.e., the project’s MVP (Minimum Viable Product) and features for a fully-fledged product’s performance.  

During the second week of the engagement phase, the developers are dedicated to 

  • Setting up scope boundaries
  • Running scope prioritization
  • Defining MVP scope
  • Creating Architecture Vision

Week 3. Portrayal

We devote the third week of the engagement phase to gathering and writing project requirements, functional, non-functional, and transactional. 

We ensure that technical project requirements are written down from a Solution-perspective, i.e., are aligned with business needs. 

To achieve this goal, software test engineers view the requirements at early stages and apply a “Requirement Checklist” that helps determine whether the conditions are complete, accurate, verifiable, and consistent. 

The tasks for the third week include: 

  • Running technical assessment session
  • Organizing requirements elicitation session 
  • Reweaving the project’s visual style 

Week 4. Result

We develop a realistic Product Roadmap that supports your Commercial Roadmap.

We also manage the technical aspects of a project to ensure that they’re in line with the company’s growth targets. 

During the last week of the engagement phase, we are busy with:

  • Gathering the Project Scope for the release 0.1
  • Writing a Resource Plan for the Scope for release 0.1 
  • Completing Requirements description 

Main deliverables of the Inception Phase

After a four-week-period, our team comes up with the following deliverables of the engagement phase: 

  • Technical Documentation 
  • System Architecture 
  • Resource Plan 
  • UI/UX Vision

Then, we move to the next phase of the project development life cycle, named the project initiation phase. 

Phase 2. Project Initiation

Before developers start writing code for your project, the team runs a quick project setup phase to gather all the necessary documentation, including the cooperation agreement, project briefs, specifications, prototypes, etc. 

The project initiation phase also ensures that all team members are aware of the project goals. As a stakeholder, you are aware of the communication plan schedule. 

The main deliverables of the project initiation phase are:

Communication plan

A communication plan is a document that specifies all the reports our team makes during the project development phase.

To create the Communication Plan, the Business Development Manager invites you and the Project Manager to a meeting to discuss further cooperation and critical project milestones. 

The Communication plan covers the schedule of:

  • Daily Scrum meetings. Their purpose is to synchronize the Project Manager with the team each day about the progress/blockers/plan for the next day. 
  • Weekly planning meetings. Once a week, the Project Manager meets the development team to prioritize tasks for the next week and improve the log review. The Project Manager writes down the incoming information from the team meeting notes to ensure important details won’t be lost. 
  • Financial reports. The Project Manager creates financial statements in PDF with a list of all the hours spent and task breakdown to the customer to ensure transparency about the monthly expenses and time spent. The customer receives the Financial report on the first day of the month.  
  • Monthly reports. The Project Manager overviews the created tasks based on requests and produces a monthly report with incoming requests from the client and requests we’ve fulfilled. 
  • Delivery meetings. The Delivery Director and Customer discuss the processes on a higher level and write down the outcomes from meeting notes. 

Kickoff meeting

After all preparations, the development team runs a kickoff meeting with you to introduce the development team members and their roles. 

The team composition and development depend on the project’s scope. An average development team composition includes the Project Manager, the Product Owner, the Technical Lead, the Quality Assurance Manager, and System Administrator. 

After the kickoff meeting, the team gets ready for the project development phase: 

  • The Project Manager and the business analyst create a project backlog with the tasks.
  • The Project Manager and the Product Owner prioritize tasks in the backlog.
  • The Project Manager, the Product Owner, and the rest of the development team estimate the first sprint, i.e., the amount of time they need to implement the required functionality.
  • The Technical Lead creates the overall project architecture.
  • The Quality Assurance manager creates a checklist for the project functionality one will use to ensure that the project’s functions work as they should
  • The System Administrator creates the GitLab CI/CD repository to deploy and store different versions of the project’s code. 
  • The System Administrator sets up the Development and the Stage environments. The Development environment is the environment for coding. The Stage (staging or pre-production) environment is the environment for testing that resembles a Production environment.

Phase 3. Project Development and QA

For most projects, we apply the scrum project development framework. This means that the scope of the project is broken down into 2-3 week sprints. At the end of the sprint, the team runs a demo of new functionality to stakeholders and releases the new functionality to the live environment. 

Sprint Planning 

Each new sprint begins with sprint planning. At the beginning of the sprint, the development team plans and determines what scope will be delivered.

If the team considers that they can’t deliver the expected result, we find extra developers that augment the team. 

At this phase, the Project Manager and the development team

  • Define a person responsible for technical leadership on the project, i.e., the tech lead
  • Implement development guidelines (design pattern, scalability, maintainability, test coverage, code review, etc.)    

Definition of Done 

The definition of done is an essential document for developers, QA managers, and project stakeholders. Definition of done is a list of requirements determining one or another feature is performed as it should, ready for deployment to a live environment, and enlightened with the tech specification. 

The development team determines the definition of done for each function of the project during spring planning: 

  • The developer estimates the required time to complete a particular task
  • The Project Manager adds the user stories and the use case to the description of the task 
  • The developer and Project Manager add conditions the job requires to perform correctly in the definition of done     

Once the team defines the project scope for the new sprint, developers begin to code project functionality. The quality assurance team tests each task right after the developer finishes coding it. 

Sprint end 

When the team has a few days before the sprint ends, the tech lead of the project dedicates a stable branch for a QA manager for project testing: 

  • QA managers run regression tests to find bugs and errors.
  • Developers fix errors and do code refactoring.
  • The team releases new functions and run a demo session with stakeholders, and gathers their feedback.
  • The team share their challenges during the sprint, potential bottlenecks for the new spring during sprint retrospective, and create the scope for the project improvement process in the case of stakeholders not being satisfied with the project demo.

Project Improvement 

Project Improvement is the scope of work developers must do so the project’s functions meet the definition of done:

  • The Project Manager establishes the improvement backlog and renews it by the end of an iteration. 
  • The Project Manager involves the stakeholders in generating the project improvement ideas and fixes them in the improvement backlog.

Backups

Before releasing the new project’s code, developers create a project repository backup. This procedure is necessary because new functions may not be compatible with tasks in the old project’s code.

Moreover, backups help us compare a previously good state of the project with the project’s current state. Finally, backups prevent data loss by ensuring that critical infrastructure wasn’t decoupled from Github by a third party that wants the breach to spread. 

The team creates a backup of GitHub repositories with critical project assets, including:

  • Codebase                        
  • Infrastructure and configuration                         
  • Databases                        

Then, QA managers test each project backup. Iteration by iteration, The team of developers does spring planning, coding, bug fixing, making backups, and testing until the final project demo. 

Phase 4. Final Demonstration

The final demonstration session of the project is a meeting of the development team and you as a project stakeholder before the project’s release. 

During the final demonstration sessions, the development team shows the project functionality written in the project technical documentation to you and other stakeholders.

After the final demonstration session, you and other stakeholders can test the product on your own in the test environment before developers upload the project to your server. 

During the next two weeks, the team provides free technical support to fix issues that are not aligned with technical requirements of the system. After the end of the two weeks, the team and you can sign a Technical Support Agreement to continue project improvement. 

Phase 5. Technical support 

Technical support is necessary for all new projects to maintain a system that can perform differently in a live environment than in a test environment. 

Technical support is also essential for ensuring the system’s stability since unexpected high traffic loads can increase project downtime and cause other technical issues. 

Tech Support Team 

The typical support team includes: 

  • The DevOps engineer maintains network health and fixes errors on the server. 
  • The support manager (or a feedback operator) gathers user requests (briefing, receiving complaints, processing applications and proposals)
  • The support developer makes any urgent changes to the project to ensure streamlined fixing of critical issues, bypassing the project improvement backlog.

2. Technical Support on 3 Levels 

At the moment, we can point out three different technical support levels that vary in respect of the project’s complexity, stakeholder’s needs, and the client’s business maturity: 

Level 1. Service desk

Under the service desk tier, the development team ensures: 

  • Processing of incidents and requests 
  • Dealing with common, typical, and previously documented issues
  • Escalating issues
  • Collecting statistics

Level 2. Issues/problem management

The second level of technical support empowers developers with more responsibilities:

  • Resolving of non-standard issues 
  • Analyzing root causes 
  • Providing workarounds and quick fixes to minimize business interruptions
  • Resolving high severity and urgent incidents

Level 3. Product development

Under the third level of technical support, almost every tech vendor provide a dedicated team that deals with

  • Developing permanent solutions to issues from rare curing
  • Releasing and deploying management to align system changes with changing business needs

3. Models of cooperation 

The model of cooperation determines the number of responsibilities a development team faces when building a project. There are three fundamental cooperation models – Managed Services, the Dedicated team, and the Extended team. Let’s explain them one by one. 

Managed Services is a cooperation model under which the team operates all product development processes. At the same time, you get the freedom and time to develop your business. This engagement model works best to build complex products, such as web or mobile applications, from scratch and provides technical support services. 

The team’s composition that works under this model may include application developers and quality assurance specialists and a product manager, UI/UX Designer, Business or System Analyst, and other team members depending on your project’s needs. 

The dedicated team model means the development team shares responsibilities with you. You can work under this model for outsourcing business functions such as development and quality assurance to empower your existing development team with our narrowed domain specialists. 

The team composition of the dedicated team model includes developers, quality assurance managers, and a dedicated Project Manager who is taking care of the Software Development Life Cycle (SDLC) Methodology and process. The Project Manager also facilitates the integration of the dedicated team with other teams on your side and third parties.

The extended team is a cooperation model under which you as a client manage all the project development processes. The comprehensive team model is popular among businesses that want to extend existing software development teams with extra professionals while avoiding finding in-house candidates and hiring costs. 

To make the extended team model work, you need to have established project management processes. Our Extended Team will inherit your existing structure and report directly to you or your project manager.

4. Project Management for Software Development Tips

Six central values that differentiate a trusted tech partner from bad ones:

Happiness as KPI. We focus on things that matter. We know how to take care of your business’s problems and turn them into solutions. 

Result-Oriented. We value your business the most. We are willing to help you with directions that yield great value where time is everything and doubts are detrimental. 

Narrow Expertise. We understand the balance between the industry’s best practices and adjusting to opportunities when they come knocking on the door.

Verified Seniority. We manage each team member’s qualifications, apply the Competence matrix, and create a Personal Development Plan to grow in-house professionals. 

Standardized Onboarding. We apply an Onboarding Plan to shorten the project onboarding process, so new team members are integrated into the project quickly and efficiently.

Project Health Check. We ensure that the project goes right by applying Project Health Check best practices to compare project characteristics and qualities with industry standards.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *