Developing the Perfect Process

Thought Leadership | Princeton Blue

In BPM development, we have all witnessed the inevitable tension between “the good” process, versus “the perfect” process, and this is when it comes down to implementing Business Process Management (BPM) solutions. As a general observation, businesses are hyper-focused on perfection (the perfect process), and in-turn developers move towards the inevitable path of developing those ideals.

In this blog we will showcase common developmental pitfalls, and methods that we have used to overcome those pitfalls. We develop a perfect process for quick wins for the business, while we must also develop to enable continuous improvement time and gain, and bring customer delight.

Below are common Development Pitfalls to Avoid to get a Perfect Process

  • Requirement Gathering

Developers often spend too much time and effort, trying to get it perfect the very first time. They must instead, take a step back and realize that there is a better way to do it when it comes to software development.

Developers need to make sure that the product delivers on all business requirements, is fully functional, so the business can complete their activities in a more efficient manner, and that the solution passes all User Acceptance Testing (UAT) before the celebrated Go-Live date. Developers do not need to fulfill all last minute changes (even though it is rather tempting), items not covered in requirements (as long as they do not prevent users from doing their work), rectify defects that are not blockers, or wish list items. It is actually more beneficial that developers wait to complete these activities for the reasons listed below.

We have all witnessed developers spending either too little, or too much time in requirements gathering and analysis. If they spent too little time, they would miss the mark and spend too much time in re-design. If they spent too much time, they would over analyze each item at a conceptual stage. They need to get the product in front of the customer before further analyzing some of the details.

  • Misuse of Agile Methodology

Agile comes to save the day, an iterative approach to software development that allows you to get a prototype in front of the customer to help iron out the specifics. Agile is a great methodology that we use today to help iron out specifics, and catch any requirement issues earlier in the process, however, it introduces a new problem. The business sees this as an opportunity to get everything they want the first time by constantly changing requirements and thinking of new items to include after each sprint. This leads into a never-ending cycle of changes, development, and testing. The business is not always aware of the time and effort it takes, to make what is seemingly a simple change. The documentation must be updated, the code must be changed, unit testing, functional testing and regression testing before being ready for release.

  • Scope Creep

As a developer, we sometimes begin to add items to the project that are seemingly small additions. What we do not realize is that we are falling into the same trap as the business above. These small additions can quickly add up to consume large amounts of time in documentation updates, test script updates and testing. We typically work under very tight and aggressive timelines that can be greatly impacted with even the smallest of changes especially when the small fix ends up becoming a much larger effort than originally planned.

Here are a few suggestions on how to avoid these pitfalls.

  • Create a wish list

Instead of allowing for constant changes, we need to create a “wish list” of items that can be completed only if time permits or after the initial installation. By creating this wish list we are able to move forward with deployment for the end users. This is where we get the best feedback from the way the application is performing and where we could make the greatest improvements. Items with a higher priority may pop up, and the label change activity, that was quite important earlier, and may have consumed around 10 hours of your time, would now be dedicated to an enhancement, that could save minutes on each transaction.

  • Implement a Change Management Plan

Change is part of the software development process. We create a change management plan upfront to address what items will be managed through the Agile methodology process and what items will need to go through the change management process. Any large changes, or requirements changes need to go through a formal change management plan, that should include the following steps:

      1. The change needs to be scoped out including level of effort, risk, and required resource(s).
      2. The change needs to be discussed with the business to determine impact on the project and if the change would require additional resources, additional time, or removing some of the existing requirements in order to free up resources.
      3. The change needs to be signed off by the business.
      4. The change needs to be discussed with the development team and assigned to the concerned developer for completion.
  • Implement a Plan of Continuous Improvement

Six Sigma has established the concept of Continuous Improvement with the idea that we are not always going to get it right the first time, but we can have a huge jump in productivity with the initial release, allowing the users to become familiar with the process/application, which in turn will help them discover new areas of improvement that can then be implemented for another huge bump in production. If we try to get it all right the first time, we will miss out on that secondary bump, that we get with continuous improvement and thereby deliver a perfect process.

To conclude, we need to keep the business focused on getting a solid product out the door in a timely manner, allowing them to use the product before we spend time making small changes that can be combined in future releases or be spent on higher priority items.

Nicholas Ankrom
Nicholas Ankrom
Nicholas Ankrom is a Consultant at Princeton Blue.

Leave a Reply

Your email address will not be published. Required fields are marked *

Want to Learn More?
CONTACT US