the BPM freak !!

Home » Posts tagged 'Measure'

Tag Archives: Measure

How to Measure Productivity in a BPM Project ??

April 27, 2012 8:55 pm / Leave a comment


Whenever it come to Project Management and Resourcing the word that is very popular is “Productivity“.

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 :

Testing Project

  • 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

Development Project

  • 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
End to End Business :

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.

Image: Idea go / FreeDigitalPhotos.net

Happy Learning!! 🙂