Project Management is all about how software teams create and follow processes that allow them to help achieve client's goal within a pre-defined timeframe and allotted budget. And the final delivery should have appropriate quality and possess features and functions described in technical requirements specs and change requests.
In many cases we have to find a balance between project time, cost and scope. Project management (PM) Triangle is a great way to find this balance:
As we see, all three values - time, cost and scope - are interconnected and if one of them changes, it affects at least one of the other two values, which demonstrates how restrictions balance with quality.
Check out a related article:
As an example, let's take a look at a situation when customer is asking you to shorten project delivery time. Your logical response as a software development provider would be: "You need to increase the budget so that we can hire more people to get the work done by your new due date." If customer tells you it's impossible to increase the budget, you need to reduce project maintenance costs, otherwise you won't be able to fulfill the scope within a shortened project time using IT talent hired to date.
So, building a quality software product on time and on budget that would fully meet customer expectations is a process that can and should be best described in project management terms. Software developer is one of the key roles in this process; using a PM triangle we can assess their level of professionalism on a regular basis by systematically comparing their work results with how they fit in a Triangle.
In the best case scenario, while working on a software dev project, developers should make sure:
- The actual time of development does't exceed time indicated in your initial Proposal to client
- Code quality fully meets pre-determined parameters and standards
- Cost of project development stays within the budget during its lifecycle
Apparently, all imposed limitations should be adequate both in terms of common sense and in terms of developer's competences and capabilities.
Why do we need to assess software developers against PM Triangle?
1. Boost HR efficiency
Objective assessment of software developer's professionalism criteria could help HR management find the right people for each particular client's project who would best meet project requirements. Having an opportunity to compare own competences to those of their colleagues allows developers to better understand what qualities / skills they have yet to improve to become higher-paid and in-demand.
2. Keep customer happy
At the end of the day, customer is the one who's most interested in getting the right specialists onboard, because the more competent the developer, the higher the quality of delivery and the lower the final cost (due to elimination / reduction of overheads, etc).
Check out a related article:
3. Extra expenses vs anticipated outcome
Price the client will have to pay on top of budget for their Team assessment is rather low compared to the result they can get in return (e.g. more accurate data collection and analytics to improve BI).
However, designing such assessment criteria requires strong formalization to be embedded right to the project spec. To date, there're 2 main paths you can take: deadline-focused and budget-focused. But before reviewing each of them, let me briefly describe a QA approach you can employ within your project teams.
In addition to standard QA methods you're using on your teams, you can get code quality metrics using open source static analyzers like SonarQube. This data can be easily compared against progress of each developer on the team as well as any part of the project or project as a whole. You may introduce a new KPI - relation between time spent on a task resolution and time spent on fixing bugs pertaining to this particular task.
Now let's get back to two possible approaches to money and time.
In order to measure indicators responsible for keeping your project within the pre-set timeframe, you need the following parameters:
- Task estimate in man-hours of a developer who'll be working on its resolution (you should get customer's approval for this)
- Information about how many hours were actually spent on this task (you need a time-tracker for this)
- Due date (ultimate deadline for task completion)
Let's not forget that the task is considered to be completed after a few people have worked on it (at least a developer and a QA engineer), which implies adequate time planning and well-established communication between team members working on the same task. What's important in this approach is that all KPIs can be measured in hours, days, etc, i.e. they are time bound.
When it comes to monetary value, there're 3 types of projects in terms of price formation:
- Fixed cost (aka fixed price) project does't imply any budget deviation
- Time & Material (T&M) project means the cost is linearly related to man-hours spent, i.e. budget deviations equal deadline deviations.
As such, fixed cost and T&M models don't provide for any budget metrics. In general, this approach suggests it's impossible to properly depict budget indicators for a particular developer in the PM Triangle; only quality and time metrics are left here.
Another approach suggests that time metrics be counted as budget metrics. Matching the deadline is calculated using calendar dates: start date, due date and actual date. In particular, a deadline metric can be measured as a number of failed / unmet deadlines pertaining to a given task, or as the following ratios: start date/due date and due date/actual date. Budget indicator is based on initial time estimate vs the actual time spent. Budget discrepancy is supposed to be calculated as an average deviation of the actually spent time from the initially estimated time.