Thunder

A client – centric framework for modern business

Challenges of effective outsourcing project management in the modern era

Managing projects efficiently and effectively is crucial in today’s modern business environment. Traditional approaches such as time & material and fixed price models often present challenges that hinder successful project delivery.

The fixed price model ensures a clearly defined project scope, objectives, and deliverables, providing predictability in project costs and timelines, and reducing administrative effort through predetermined scope and expenses. However, it lacks the necessary flexibility to address unforeseen issues and evolving needs, and offers limited insight into the project until its conclusion, posing a risk to overall success.

While the time & material model provides flexibility in project scope and costs, as well as the necessary adaptability to evolving and emerging issues, along with transparent insight and control, it does carry the potential for cost overruns. Moreover, it lacks fixed timelines and demands higher client involvement due to ongoing negotiation and change management, consequently increasing decision-making time.

To mitigate the limitations of the traditional project management models, here we introduce a superior Scrum based business alternative dubbed Thunder, which offers numerous benefits both for the client and RT-RK.

The comparison between traditional business models and the Thunder model is illustrated in Table 1. Thunder exhibits resemblances to the time & material model, albeit with a pronounced emphasis on delivering tangible results for which the customer pays. The success of the Thunder approach hinges significantly on customer support and finds its application in projects with a high level of customer commitment.

Fixed price Time & Material Thunder
Project preparation on both ends involves a complex and costly process of defining the project scope and acceptance criteria Yes No No
Customer is paying for the results Yes No Yes
Flexibility is key, allowing for agile team engagement that adapts based on progress and the availability of inputs No Yes Yes
High demand for change requests and significant overhead in tracking dependencies Yes No No
Seamless integration between the Customer and Client, embracing their respective work styles, fosters intercultural synergy No Yes Yes

Table 1. Thunder vs traditional business models

Introducing the Thunder way of working

The Thunder way of working offers a modern and effective business model for project management, addressing the limitations of traditional approaches. By embracing this innovative methodology, businesses can achieve greater control, transparency, cooperation, and cost management, leading to successful project outcomes and satisfied stakeholders.

The Thunder approach ensures a distinct allocation of responsibilities, encompassing well-defined roles and duties for all stakeholders, and facilitating smooth communication and efficient decision-making processes. Furthermore, it emphasizes transparency in planning and work progress. A comprehensive view of project planning and real-time tracking of milestones, tasks, and deliverables is readily accessible. This approach encourages close and optimal collaboration between engineering teams and enhances the efficient utilization of resources and expertise. Finally, Thunder provides enhanced control over project expenses. Pricing is contingent on completed work rather than the time spent on the project, mitigating unexpected costs, and preventing budget overruns.

Sprint velocity: the key factor in tracking project efficiency

To proceed further, readers should be acquainted with the term ‘story point’ in Scrum. Story points are linked to each item in the sprint backlog and are determined based on the type of item and the work required. The assignment of story points is influenced by inputs from the client regarding requirements and priorities. RT-RK can also contribute to determining these story points.

Image 1. Backlog, sprint, and story points

To establish a client–centric framework, Thunder introduces sprint velocity as a metric for gauging project efficiency. Planned sprint velocity is determined by summing up the planned sprint points, while actual sprint velocity is the total of executed sprint points during the sprint. The efficiency of the sprint is subsequently calculated as a percentage, comparing the actual velocity with the planned velocity, as illustrated in image 2.

Image 2. Planned and actual sprint velocity

The price of the sprint is determined based on the calculated efficiency, using the following equations

Efficiency > 85%

Efficiency < 85%

Diving into details

Let us illustrate the Thunder approach, starting from sprint preparation, through execution, and up to sprint closure, as depicted in image 4. Each sprint has a duration of 3 weeks. The sprints overlap, with the next sprint being prepared during the execution of the current sprint and concluding during the execution of the subsequent sprint, as illustrated in image 3.

Image 3. Overlapping sprints

In the sprint preparation phase, the sprint goals, ‘ready,’ and ‘done’ are clearly defined, along with the meaning of ‘testing.’ Additionally, any unclosed tasks from the previous sprint are registered. The output of the sprint preparation phase is a sprint plan.

During the sprint execution phase, a sprint burndown report is created. Weekly meetings are mandatory, while daily meetings occur as needed. Unfinished tasks from the previous sprint are finalized in this phase. The sprint burndown progress vs velocity report is also available during this phase.

In the sprint closure phase, items are either accepted as closed, or an alignment is achieved for their new status (replanned in the new sprint or closed with comments or an action plan). Both technical and commercial reports are provided by RT-RK in the sprint closure phase. The details of each phase can be found in Table 2. The rough sprint timeline with responsibilities can be found in image 5.

Image 4. Thunder phases explained

In the sprint preparation phase, the client provides a list of sprint items, specifying their priority, a rough estimation of story points, and a clear definition of sprint goals. RT-RK reviews and confirms/comments on the list. A final sprint preparation meeting is held where RT-RK and the client mutually agree on the plan to be executed.

During sprint execution, the RT-RK Scrum team meets daily (attendance by the customer is optional) to discuss technical status, a list of issues, and other relevant matters. Weekly meetings are held between the RT-RK team and the customer to discuss the weekly status, sprint progress, any blocking issues, and potential re-planning or re-prioritization. RT-RK provides a weekly report that includes updates on sprint item progress, a burndown report, and a comparison of burndown progress versus velocity.

In the sprint closure phase, RT-RK delivers a sprint closure report encompassing status updates, comments, and any remaining unclosed items. The client either accepts the report, or a meeting is scheduled to align on the report and create a follow-up action plan. Additionally, RT-RK provides a commercial report based on the project’s status.

Table 2. Thunder phases continued

Image 5. Rough sprint timeline with responsibilities

Example

Let’s illustrate the Thunder approach using a project example that involves testing, considering the following:

  • The team price is calculated as the sum of individual prices for team members (This is the price that could be invoiced in pure time & material model).
  • The team comprises one expert and two senior members.
  • The sprint duration is 3 weeks.

Additionally, let’s assume that not all team members are engaged every day of the sprint (due to reasons such as vacation), and the backlog contains a total of 18 tests, out of which 5 tests are only partially feasible (with lower weight in story points).

For the purpose of this example, let’s assume that the daily engagement cost is 1520 $ for an expert and 1420 $ for a senior.

In this scenario (as depicted in image 6), the sprint’s base price is calculated at 43100 $. If fully implemented tests carry a weight of three story points and partially implemented tests have a weight of two story points in the sprint, the total sprint content is 49 story points. Considering that 85% of 49 story points amounts to 42 story points, any sprint efficiency below 42 points is invoiced at (realized story points/planned story points)/0,85 x full price. However, if the sprint efficiency equals or exceeds 42 story points, the full price of the sprint is invoiced.

Image 6. Example of invoicing