How ideas turn into code: a glimpse into project management methology

From a high-level perspective, a software development project from the initial idea to the final delivered product is a process, involving tight collaboration between various roles. It's worth mentioning that software development, defined as code, is generally just one part of the whole solution.

 

The reason is simple: large and impactful projects are inherently complex. This complexity means that not even the most capable individual developer can be expected to encompass the entirety of the scope. The solution lies in a skillset and role-based distribution among specialists.

 

Similar to manufacturing – there are influencers, analysts and planners, there are executors, and quality controllers. In this article based on a simple example, I'll share experiences and thoughts on the software development process regarding insights to consider when on a journey turning ideas into code.

 

 

The evolution and significance of user-centric design

You, like many others, have presumably noticed a strong drive towards user centred design in the last 10-15 years. Web applications, e-marketplaces, and tools we use today are much more intuitively usable and accessible (WCAG). This drive is not accidental, on the contrary it is a very purposeful directed effort.

 

The cornerstone of user centred design is methodical attention to detail, particularly emphasised in the preparatory phases of a project. Such an approach allows development projects to focus on the aspects of most importance and address issues that hold the highest value for end-users. The more resources directed towards gaining purposeful value, the swifter the return on investment. 

 

 

Firstly, let’s assemble a team

Solutions to tough challenges rarely emerge from a vacuum. In order to understand the relationships between roles, let’s assemble a team.

 

Imagine a corporate intranet project aimed to collect orders made by users, manage those orders and users, gather and generate statistics. The application interacts with enterprise resource planning software (ERP) and enables automated generation of invoices of orders.

 

Inquisitively, we delve deeper: who are the users, and what are their habits? How do users register and log in? What products are being sold? Where does product information come from? Can different users have different purchasing conditions and price lists? What activities does the administrative process involve? Based on what criteria and under what conditions is statistics generated? What type of ERP are we dealing with, and does it have a functional interface? Does the ERP create and generate invoices, or does the intranet?

 

There are always so many questions that comprehensive preparation from every angle is near impossible. The best practice for solving such complex problems is thus a targeted and role-based distribution of activities and preparations.

 

To address the tough challenge, we assemble a team of specialists:

 

Analyst

• Objective: thoroughly compile and document all functional and non-functional requirements and use cases related to the project.
• Outputs: Analysis documentation (preliminary or detailed analysis), development tickets.

 

User Experience Designer (UX)

• Objective: investigate what the end user truly needs and define personas. Create a prototype and test it on end users.
• Outputs: user personas, wireframes, user scenarios.

 

User Interface Designer (UI)

• Objective: create a visually consistent and appealing user interface design based on the tested prototype and the company's visual identity.
• Outputs: user interface design and related module elements.

 

Back-end Developer (BE)

• Objective: based on the analysis, define the architecture and create a functional data structure for storing and modifying user and product information. Develop necessary integrations to serve both internal and external communication.
• Outputs: development code, linked databases, SQL queries, defined systemic constraints and permissions.

 

Front-end Developer (FE)

• Objective: based on the analysis, user interface design and the rights and constraints specified by the back-end development, create a functionally operational and user-friendly visual.
• Outputs: visual development code, integration with backend systems, compliance with WCAG standards and user interface requirements.

 

Software Tester

• Objective: through a methodical approach, identify deficiencies in the solution created by developers, comparing them against analysis, UI design, and non-functional requirements.
• Outputs: Tested application, development tickets.

 

It's worth mentioning that in such a team, the number of specialists and roles filled need not hold a 1:1 relationship. Depending on the complexity, scope, and timeline of the project, multiple team members may fill one role, or one team member may simultaneously participate in multiple roles.

 

For example, a designer in the team could simultaneously hold both the user experience (UX) and user interface (UI) designer roles. Similarly, a full-stack developer in the team could act as both a front-end (FE) and back-end (BE) developer simultaneously.

 

An exception lies in the separation of roles in service design and software development. This is because the skill sets of designers and developers are different enough not to have significant overlap. Exceptions prove the rule and consequently there are instances of previously code savvy designers.

 

Numerous examples of software testers turned developer as well as analysts who have dabbled in design and/or code. Diversity is great since modern software development relies on close collaboration. A deep understanding of various roles and activities provides the team with a strong advantage.

 

 

Secondly, let us consider the sequence of activities

We have assembled the team and are ready to face challenges, but what's next? Simply, software development relies on three pillars:

 

• Preparatory Process (Green) - Gathering, grouping, visualizing, and presenting knowledge, materials and needs. This phase involves preparing the groundwork for the project.
• Execution Process (Orange) - software development in accordance with the described requirements and needs. 
• Control Process (Blue) - looking for differences between materials, needs grouped and software developed. This phase involves testing and quality control to ensure that the developed solution meets the specified requirements.

 

 

By breaking down the software development process into these three key pillars, it becomes easier to understand the flow of activities from initial preparation to the final quality assurance. Each phase builds upon the previous one, creating a logical and systematic progression throughout the development lifecycle.

 

When planning for changes it is important to consider, the sooner the changes are introduced the less costly the changes are to introduce. As an example, a change introduced in the analysis phase might involve modifying task descriptions. However, changes in testing might require input from every other role and thus turn out much more expensive to implement.

 

 

Great challenges require a methodical approach - let's be agile!

Within a team, roles and specialists are interconnected through continuous and immediate communication. Since the agile approach to development is built around direct communication it is wise to be agile. You can read more about agile development in our previous article.

 

On the journey of bringing an idea to life with code, two larger and related processes must be traversed: the preparation process stage and the development process stage. The preparatory process is traversed once, the development process is repeated iteratively. 

 

 

1. Preparation process

The aim is to address, gather, interview, and analyse the input provided and work to be planned. The end result is a preliminary analysis describing the general nature of the project, business requirements and functionalities. Based on this dataset, it is possible to assess the tasks involved and visualise them in a roadmap.

 

2. Development process

The goal is to in detail define, design, estimate, and execute the work. One cycle focuses on one specific development epic and may include multiple development sprints.

 

Preparation process:

Everything cannot be done all at once. Thus every complex task must be divided and planned in sizable chunks. The preparation process can be viewed through the following activities.

 

1. Familiarisation of input materials

• Objective: to become acquainted with the materials and general ideas/solutions prepared by the client for the implementation of the project.
• Roles: Product Owner, Analyst, Project Manager, UX Designer, UI Designer.
• Outcome: A general understanding of the project's nature and the preparation of substantive questions and hypotheses for interviews.

2. Stakeholder interviews and preliminary analysis

• Objective: to reach a more detailed understanding of specific business and functional requirements necessary for the project's completion. Conduct interviews with key internal and external stakeholders to map their views on expectations, concerns, and needs.
• Roles: Product Owner, Analyst, Project Manager, UX Designer, UI Designer.
• Outcome: Categorised and combined interview results. Preliminary analysis document describing project needs and elements development. The analysis is generally superficial and focuses on describing the project at the general functionalities level.

3. Segmenting preliminary analysis into primary development epics (Epic - Story)

• Objective: to generate a general list of needs (story) and divide them into larger development cycles (epic).
• Roles: Analyst, Project Manager, Product Owner, UX Designer where necessary.
• Outcome: List of development epics and functionalities.

4. Defining the overall Scope

• Objective: to use the preliminary analysis and the list of development epics as a basis for defining the overall development scope. Introduce the planned solution to the development team, give rough development estimations.
• Roles: Analyst, Project Manager, UX Designer, UI Designer, Developer, Product Owner.
• Outcome: a list of functionalities with time estimations.

5. Creating a rough development timeline (Roadmap)

• Objective: Create a timeline based on the estimated scope and planned resources.
• Roles: Project Manager, Analyst, Product Owner.
• Outcome: General timeline for the implementation of developments.

 

Using our imaginary intranet project as an example we can see that it too  is built from various epics: registration and login, user management, product management, order processing, statistics management, and invoice generation.

 

When constructing a roadmap, it's important to consider the sequence of development epics. In this example, you can't generate invoices without orders. Orders in turn can't be processed without products and users. This means it makes sense to start development from epics that serve as prerequisites for subsequent epics. 

 

Development process:

The cornerstone of the development project is detailed research and analysis. The goal of the research is to understand and map the various components of the project and provide developers with a visual/documentary foundation for executing development.

 

The detailed analysis becomes the "source of truth" throughout the project. Agile is based on an iterative, regular, and cyclical method of developing features. As an addition this allows separate roles to work in parallel. 

 

The functional content of the work is open and subject to change. In comparison to traditional waterfall-type project management, agile development does not focus on completing the entire analysis and design before the start of software development. In agile methodology, design and analysis are performed just in time or in other words just before the start of the execution process.

 

 

1. Setting focus on a specific Epic

• Objective: Based on the development plan, address one selected development functionality (epic). Prerequisites must already be in place or created within the process of development.
• Roles: Analyst, Project Manager.
• Outcome: Targeted stage to be addressed.

2. Gathering ideas

• Objective: to define a specific plan, gathering additional questions and answers.
• Roles: Analyst, UX Designer, UI Designer.
• Outcome: Creation and compilation of materials, grounding hypothesis.

3. Writing detailed analysis, working on UX/UI design

• Objective: to define in detail all elements necessary for execution. The detailed analysis is based on specific use cases, focusing on "User A opens B, does C, and the result is D." The level of detail covers the specific input-output relationship and addresses both the created user interface and technical requirementsl.
• Roles: Analyst, UX Designer, UI Designer.
• Outcome: Detailed analysis of a specific development cycle that can be developed and tested.

4. Creating development tickets

• Objective: to formulate the use cases defined in detailed analysis into achievable development tickets. A use case may exceptionally include several different tickets for comprehensive implementation, distributed among different executing roles.
• Roles: Analyst.
• Outcome: Development tickets related to and described in the detailed analysis, ready for presentation, assessment, and execution.

5. Development ticket refinement

• Objective: to present the planned functionality, created tickets, and their content to the development team. Developers provide an estimated assessment for planning purposes.
• Roles: Analyst, if necessary, UI Designer, Developer.
• Outcome: Assessed, explained, and planned development tickets.

6. Closing the old and planning the new sprint

• Objective: Sprint planning (demonstration of completed work, closure of the previous sprint, retrospective review of the past sprint, planning for the new sprint). Sprint planning considers the current state of completed work and the volume of planned functionalities. The team's time resource capability for executing developments is also taken into account. Planning relies on the estimates of development tickets. Sprint duration is 2-4 work weeks.
• Roles: Analyst, Project Manager, UI Designer, UX Designer, Tester, Developer.
• Outcome: Planned, achievable and limited development goal..

7. Sprint execution

• Objective: Fulfil the development tickets planned for the sprint.
• Roles: Developer, Tester, Analyst, UI Designer, UX Designer, Project Manager.
• Outcome: Functionality achieved as planned for the sprint.

 

 
In Conclusion

Turning a bold and inspiring idea into code is a process that involves the close collaboration of various individuals and roles. The connection and collaboration between roles can be viewed as a sequence of activities through which user centric functionality is created. Hopefully I have managed to show that  through the process of continuous communication and mindful segmentation of tasks even the most complex ideas can successfully be turned into code.