Resources

When a business standardizes one of its processes, it is justified, financed and sustained within the boundaries of a business process management project charter. Therefore, a project charter defines the issue to be resolved, the scope and the goals of the undertaking and the roles and responsibilities of the parties involved. It is a contract between the management and the team that will implement the change.

In light of the above, this article will highlight how to write a business process management project charter.

To start with, there is no single way to write a project charter. The length and format are purely in the prerogative of the writer. However, if you want it to be read, write a brief one. The ideal project charter should be 2 pages maximum; if you really have to exceed this, then 5 page is your final limit.

I worked with an Agile Coach who used to be a development manager and was famous for telling people he could expect a 5-10% attrition of his employees when Agile was getting introduced. It begs the question of why in the world an organization would be willing to undergo such a disruptive change in how they work, knowing that such a large portion of their current staff will consider leaving because of it? For many organizations, the answer became self-apparent. They have recognized the need to be faster, more adaptive in their market. They became self-aware in knowing that, without such a change, they would quickly become an afterthought. So, the need for change is apparent but how does an organization deal with the inherent personnel issues that could come with adopting an Agile culture? By not taking this part of the change into serious consideration, you could be inadvertently undermining your entire transition into an Agile organization!

When analyzing a function for improvement, it is common practice to document the existing operations into what is widely known as a current state. This current state operational view serves as a baseline for improvements. It identifies the inputs, work steps, and outputs (and often a lot more). It serves to ground the team and provide a starting point for designing a future state. In contrast, future states are the destination. They are the sum total of the improvements to the current state to get to a new more effective and efficient operational state. Generally current state and future state views are documented as process maps or flows. Both the current state and the future state are powerful steps for improvement teams to understand where they are today and where they are going in the future.

Let me start with a definition of agile as it applies to operating models or processes: “being able to turn on a dime for a dime” and “being able to change faster and more cheaply than your competitors”.   These phrases are taken from, who was part of the team who coined the term agile as being relevant to the lean and six sigma community.  In this community, agile is associated with short-period (often six-week), test-and-learn projects, at the end of which priorities and direction can be reset based on what has been learned.  It is also associated with “minimum viable product”: the way of testing a new idea.

In today’s demanding business environment that rewards flexibility, speed, quality, efficiency, effectiveness and innovation, a strategically competitive middle- and back-office strategy and its operational execution can be a roadmap to achieve sustainable competitive advantage. Business Process Management (BPM) helps an asset management company achieve these characteristics in the components of its value chain.  Applying the BPM discipline achieves measurable process improvements that lead to organizational performance improvements in the middle- and back-office.

Middle- and BACK-OFFICE challenges

Delivering Agile Projects within Structured Project, Process and Quality Management Frameworks

The most important factor in successful Agile adoption (and expansion) is aligning it to the culture, standards and constraints of your organization.  Even the most effective Agile project work risks losing executive support if it cannot meet the overarching management, compliance, administrative and reporting structures established by the organization.  Unless you are in the unique position of being able to adjust your organizational structures to suit the flexibility of Agile approaches, you will need to find a way for your team’s Agile work to comply with these corporate standards.  Thankfully, this is an achievable goal, although it may take some creative thinking to make it work within your specific organizational constraints.

Once you have your current state model, what do you do with it? How do you share it with the Process Owner and Executive Sponsor and spark their interest? My experience is that executives looking at a model that is 30 to 60 steps long are impressed and say something like, “Wow, that process is complex. I can see it has a lot of steps which could take a long time.” But they are not interested in reviewing every single step and getting into the details.

Tell me if this sounds familiar. Organization A decides to adopt Agile methods and begin the lengthy and possibly (probably) expensive transformation process. In doing so they engage in lots of training, read books, attend conferences and listen to webinars. They engage a consulting organization to help coach the change. But, after a period of time has gone by someone brilliantly asks, “So, are we better for having done this?” Great question. Many companies have no idea whether or not these Agile methods are actually helping the bottom line and the way we deliver overall. We figure that if teams are sprinting and doing retrospectives we must be better. If teams are co-located and I see sticky notes on the wall, we must be better.

Projects create a maelstrom of documentation – charters, workplans, issues logs, process flows, requirements, solution designs, parking lots, and many more. With the deluge, invariably some of the documentation is relegated to the hard drive of death – hidden out of the view of those who might benefit from its availability.

OK, you have completed a successful pilot BPM project and your organization is now committed to a major enterprise BPM initiative.  There are many steps you need to undertake now, too many for a single article such as this, but in this article we will explore one which is often overlooked.   The BPM industry, both tool vendors and consultants, like to talk about how much simpler it is to develop solutions with BPM than with traditional programming tools.  While this is certainly true, too many organizations interpret this as license to short-cut the disciplines which they have found to be necessary in all other forms of solution development.  This article will discuss the importance of modeling standards, provide guidelines on how to develop appropriate standards and perhaps most important how to make them an integral part of your process.