Productivity literally refers to “the measure of the efficiency of production“.
There are different types of Project implemented in IT, but the approach for measuring the efficiency is not the same for all scenarios. Following are the different types of Projects :
- The Number of Defects Raised for an application or on a daily basis can be considered as the measure of productivity
- The Number of Test cases Passed and failed can also be used as an attribute
- The Number of Lines of Code implemented and
- The Number of Defects raised can be considered as the pointers for calculating the Productivity of a Project
From an end-to-end business front the Productivity is basically measured based on the “ROI” (Return on Investment)
- Throughout the BPM Lifecycle, it’s just not the IT fraternity that is a part of but even the Business also drives the same.
- Things that effect the RoI are, design, implementation, performance, alerts, response time, CPU Usage Number of Resolved Cases, Number of Best Practices Met. Performance and Monitoring Tools, which facilitate in having a Hawk Eye on the system can be used as a measuring stick.
- Even the Number Resolved Tickets and Open Tickets say the story from a Productivity standpoint
BPM Projects :
Thinking back of the core Java J2EE Projects, the productivity can be easily measured at a glance by looking at the Number of Lines of Code implemented and the Number of Defects raised.
But, to be precise BPM(Business Process Management) Products are like Black Boxes (packaged). We don’t have enough information related to the Code Volume and moreover it would not fetch any value too. So the Optimal use of the OOTB (Out of the Box) Features along with the timespan for implementing a Usecase becomes Crucial.
Lets, take a step back. Whenever we are in the RFP Stage or the Effort Estimation or the due-diligence stage, we highlight the complexity and the man-hours that are required for executing a Usecase or a Requirement in a particular Sprint.
But, due to some Infrastructure or any unforeseen scenario the timelines and efforts get affected. So, in order to justify it from a Developer standpoint, the Effort needs to be collected during each stage of the Checkin of a File along with any additional delta effort(very similar to the Timesheet Entry for the day – that most company have it)
Any deviation or excess of the effort aggregated can be highlighted and showcased to glow a red/amber/green signal.
This may sound very theoritical, but Pegasystems has a BPM Framework named “Project Management Framework” which almost does the same job very well in capturing the Efforts from the developer while creating a new Rule or Checking in a New Rule.
Here is a quick snapshot as to how the Efforts are captured for any implementation or a rule that is created or modified.
Please do share your story-line on the different metrices and attributes used by the Product to calculate the Productivity and Efficiency of the developer in a BPM Delivery Project.
Happy Learning!! 🙂