All About Requirements

Project Management in Business Process Management Projects

Projects involving business process analysis or business process redesign needs people with different sets of competences. In fact you need to map characteristics from the following three domains to success with business projects:

The skills domains involves different sets of underlying skills

 - a few examples are given below:

1. Management (in general)
   1. Management skills
   2. Team management
   3. Conflict solving    
2. Project Management
   1. Project Management Methodology
   2. Project Management best practices
   3. Planning techniques
   4. Project Governance
   5. Project Management tools
3. Business Process Management
   1. Business Process Analysis
   2. Business Process Methodology
   3. Business Process re-design
   4. Business Process mapping

 

Of course there are overlaps in the three skills mentioned above, which is illustrated below.  Often the focus is on ensuring that the right management skills are present, by allocating a strong project manager with the skills: general management skills and project management skills. But so succeed with business oriented projects you need to cover the sweet spot in the illustration below: ensuring that all three management skills needed are present in the project team.

 

 

 

 

 

Checklist for your projects resource situation:

1. Do you have a project manager allocated to the project, and is she having the basic general management skills?
2.  Does the business impact on the project reflect the allocated business management skills?
3. Is the project manager aware of the need for business management skills?
4.  Does the project plan include a documented business process method approach?
5. Is the project board aware of that business process management and project management are equally important in business oriented projects?

 

Answering 'No' to questions on the checklist above should raise corresponding risks on the projects risk log. 

 

 

Setting expectations to requirements cooperation between Business Analyst and Software Architects

A few years ago I was in France, enjoying my summer vacation. I rented a car and drove around in the beautiful landscape of southern France. A very peculiar situation took place while driving through a small village; the car in front of me stopped and blocked my way forward. The driver in the other car jumped out and approached me. When he was up close he asked, in English, if I knew the direction of another small village. I actually knew the direction, but I was so much taken by surprise, that I couldn’t communicate it clear. I hesitated a few seconds. The other driver shouted something like “damn you French people, why can’t you speak anything but French” and returned very upset to his car.  

 

What I experienced back then was similar to what I sometimes experience in projects, where the business analysts and developers try to reach out for each other, but assumptions are blocking the way forward. Sometimes there is a clash of beliefs in how to approach a project, gather the requirements and develop the system.

 

It is crucial for your chances of project success to solve these conflicts.

 

 

Three of the dominant roles in IT projects are shown below (these roles are taken from the Rational Unified Process – see: http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process)

 

• Business Analyst
• Software Architect
• Implementer

 

The majority of the activities for each role lie within the disciplines shown below:

 

A challenge here could be that the Business Analyst is gathering the requirements and business analysis but the Software Architect is the one going to design the solution, based on the deliverables from the Business Analyst. In other words they need to understand each other and they need to agree on the content and quality of the work. It will not work if the Business Analyst delivers state-of-the-art work while the Software Architect does not understand the material produced or (even worse) disregards the work produced and creates his own requirement and analysis. Does it sound unlikely to happen – I can ensure you, it is not.

 

What I usually recommend in order to deal with these kinds of conflicts is to avoid “over-the-fence-deliverables” where you simply deliver the completed work, hands it over to the next Role/discipline and steps out of the process. Instead, try to develop the work in cooperation. For instance you could develop the use cases up to a 50% completeness and let the supplier take them from 50% to complete, in cooperation with you. Or, you could let the Software Architect on an early stage review the work being produced and you could review the deliverables form the Software Architect ensuring that the design fulfills the business requirements.

 

Below I have illustrated the handshake you need to obtain – the Business Analyst agreeing with the Software Architect (or supplier, or any other receiver of the work) how to cooperate in the grey area between business requirements and solution design. If you don’t get that handshake your project is challenged. Be aware that it is usually not enough to agree on something high-level written approach – make some real examples and to a proof of concept.

 

 

I am not saying that you should accept your state-of-the-art requirements material to be transformed into something you do not feel comfortable about. But, if the receivers of the material do not understand it or choose to disregard it (it happens) – then you must address that issue.

 

 

The figure above is a nice way to quickly determine if your requirements approach is on the right track. In quadrant 1 you have a receiver of the work that understands the use of use cases (in this example it’s use cases, but could be any requirements deliverable technique) and the receiver is accepting to consider the use cases as the true requirements for the solution. This is the preferred situation, and you have the foundation for starting the project successfully,

 

If the receiver of the work accepts the use of use cases as the true requirements foundation for the project, but doesn’t have a clue about how to use and read use cases you are in quadrant 2. This is challenging your project. Depending on the receivers use case skill level you should try to educate and facilitate the process so that the receiver is guided forward – for example by introducing use case workshops and accompanying the use cases with proto types. If you are in quadrant 2 you should expect a considerable amount of extra work to end up at your internal business analyst team, and you should adjust your project economy to address that.

 

In quadrant 3 you have a very undesirable situation. The receiver of the work has the correct skill level but refuses to consider the use cases as the true requirements foundation for the project. Maybe the developers prefer to be agile without reading any requirements specification at all; maybe the Software Architect likes to gather the requirements himself, by talking directly with the end users. This means war. You will end up spending a lot of hours fighting and discussing. If you are in quadrant 3 you should consider if the project is better off being closed or postponed. Alternatively you could consider making a compromise by creating another concept of requirements foundation that satisfies both parties. Quadrant 3 is poison for your project especially if the project in the first place is risky and/or complex.

 

Finally Quadrant 4. Don’t go there. It is as simple as that. Your project is likely to fail in terms of not fulfilling 

 

Building a BPM Toolbox

The BPM knowledge area is broad and sometimes confusing. As I have described in the post http://www.allaboutrequirements.com/2011/06/what-is-bpm-bpms-ea-bpa-a-short-definition-introduction.htmlBPM is many things and you will have a hard time finding a methodology that cover all aspects under the BPM umbrella.

Often teams new to BPM are confused by the lack of a well-known cover-it-all-methodology and will ask for a methodology to be adopted. Methods do exist out there. Just to mention a few:

 

Business Process

•  Six Sigma
•  Lean
•  Kaizen
•  ITIL
•  Rummler-Brache
•  ToGaf
• Rational Unified Process

System Development

•  Scrum
•  RAD
•  FDD (Feature Driven Development)
•  XP
• Rational Unified Process

Project Management

•  Prince2
•  PMI PMBOK

Change Management

•  ADKAR
•  Kotter

 

However, in your organisation is new to BPM, it will probably benefit much more from introducing techniques and customised guides on how to approach BPM tasks/projects (see:  http://www.allaboutrequirements.com/2011/07/using-bpm-maturity-model-for-inspiration-when-implementing-bpm.html). In other words you should be inspired by the best from the methods (preferably from the methods you already know) and build your own BPM toolbox. According to a Gartner survey approx. 33% choose to develop their own toolbox.

 

Your toolbox should consist of techniques describing what to develop, methods describing how to approach the techniques, frameworks used for creating the technique deliverables, and finally tools to use when producing the technique deliverables.

 

For example as the picture below shows you could have chosen the technique AS-IS Analysis for your toolbox. And you could have chosen to use the BPMN notation when creating your AS-IS Analysis. In addition you could have created a document describing the method for creating the AS-IS Analysis (How to start, what to do first, who to interview, how to document etc.).

 

 

The concept of a BPM toolbox can be illustrated as shown below.

  
 

Below is an example of a BPM Toolbox, showing what content could be included.

  
 

 

 

Using BPM Maturity Model for inspiration when implementing BPM

Business process management becomes more and more important in a world of ever increasing business changes and an increasing search for a competitive edge.

 

But many organisations are struggling with finding a way to implement BPM principles. It is not an easy task. The difficult part is often to figure out where to start and to plan adoption of BPM principles when they are relevant for you.

 

A way to get guidance on how to approach implementing BPM in your organisation is to be inspired by various BPM maturity models.

 

BPM maturity models are models where you, typically through a questionnaire or interviews, get a score that place you on one of the steps on the maturity model ladder.

 

Related to each step is a characteristic description and guidance towards elements needed to implement in order to move to the next level.

 

The concept of measuring maturity is not new. Popularity in measuring maturity has increased since the Software Engineering Institute at Carnegie Mellon University released the Capability Maturity Model in the early '90's (for measuring software development maturity).

 

Gartner Inc. has developed a model for measuring an organisation’s BPM maturity. Gartner is not alone in this field - e.g. OMG has a maturity model as well.

 

In general you can say that the maturity models provide you with a guide on how your organisation can implement BPM in a structured way. Gartner, for instance identifies in their maturity model six phases for BPM implementation.

 

Here is a short list of quick wins tips when implementing BPM (for small+medium+not+so+mature organisations):

 

1. Don't rely on the maturity models - use them for inspiration. The focus in these maturity models are on large organisations. In my opinion you can end up with a very time consuming process if you follow the maturity model track in details.

 

2. Don't focus on tools, focus on processes. Often organisations starting adopting BPM start buying a modelling tool and focus on getting the best tool with nice features. This approach will not bring you business value very fast.

 

3. Agree on standards and frameworks. Start with establishing common understanding of what techniques and standards to use. Later on you can discuss methods and modelling tools.

 

4. Establish a competence team. Find out who is the BPM champion and let that person/team lead the BPM implementation.

 

5. Avoid theoretically discussions - work on a real project. Get started with a real project. Test what works in the field and what doesn't.

 

6. Be selective - what works for you? What brings you business value? Even though a template or a framework tells you to do things in a certain way, if it doesn't work for your organisation you should remove it.

 

7. Be aware of templates. Templates are great but don't be a slave to templates (see tip # 6)

 

8. Don't force your organisation to adopt more than it can consume. Here the maturity models are great for inspiration. Always learn to crawl before learning to walk.

 

9. Don't over complicate BPM. After all BPM is just a managing technique. Make sure it brings business value instantly and avoid too deep theoretically discussions.

 

10. Focus on bringing business value fast.

 

Fast-track tips for bringing business value in your way up the BPM maturity ladder:

 

Starters - Level1 - starting adopting BPM:

• Focus on BPM techniques.
• Use simple tools to get started - e.g. just paper and sticky notes
• Focus on understanding business problems

 

Highlights when moving from level1 to level2:

 

• Move from paper, sticky notes and drawing tools to modelling tools
• Document and manage your BPM techniques. Notice that you probably only have adopted techniques at this stage (e.g. AS-IS TO-BE modelling) but probably have not adopted methods (specifying how to do it).
• Focus on solving business problems by reordering processes, removing redundant processes, run processes in parallel, etc.

 

Highlights when moving from level2 to level3:

 

• Establish a formal process competence team that owns and drives methods and guidelines
• Establish methods on how to approach BPM
• Establish templates, guides, training materials etc.
• Focus on performance indicators
• Focus on automation and IT supporting processes

 

Highlights when moving from level3 and upwards:

 

• Focus on BPMS
• Focus on process performance measure
• Focus on process simulation
• Tie the process execution to the corporate strategy
• Make sure all initiatives are process driven

 

If you want to dig into the details of BPM Maturity Model I recommend getting the Gartner document “BPM Maturity Model Identifies Six Phases for Successful BPM Adoption” and see for yourself.

 

Change Management for Business Processes

Allright, we've build a new system which fulfils the business requirements (thanks to our Business Process Analysis outputs: AS-IS processes and TO-BE processes and structured requirements capturing).

Everything is in place and all there is left to do is implement the system and train the users.

Really? one important part is missing: Change Management!

Although I think training is an important part of change management it seems to be far from enough, keep in mind that Business processes are about people. If people don't change the change management process will be unsuccessful.

A key element to a successfull change management process is to consider all the stakeholders as individuals that need to be informed, managed, trained and involved so that each one of them become ambassadeurs for the project.

If not, the overall project will face difficulties. Often, after implementing a new system and a new process, if change management has been unsuccessful, the users will avoid the new ways of doing things, invent workarounds and keep doing as they've always done.

 

Never underestimate the users ability to avoid using your brand new system.

An effective way to seeing change management is to consider the stakeholders as a group of individuals that need to go from the scepticism platform to the ambassador platform. Make a plan on how to do that. For example inform, train, and involve stakeholders. And most important communicate why changes are needed.

 

 

 

A strategy to successful change management could be:

1. Identify the stakeholders
2. Group the stakeholders by their interest in the project
3. Plan how to transfer individuals from the scepticism platform to the ambassador platform.
4. Keep track on the statistics. Measure if it's working - are more people transferring from the scepticism platform?

 

Prosci have developed a great change management model called ADKAR Model:

 

Awareness - Recognise the need for change.

Desire - Who needs to participate (stakeholders)

Knowledge - Who can guide the change management process?

Ability - Who will implement change behaviors?

Reinforcement - Who will lay the foundation for change now and in the future

Trends In Business Process Management - What Will We See In The Future?

In this post I will try to lift the curtains for what I believe will happen in the future in regards of business process management.

The outlooks are very interesting business process management will probably get a key role in the future businesses.

 

Everything will be social

In the future everything will be social is predicted by Facebook founder Mark Zuckerberg and a lot of things indicated that this will will be correct. Social Business Process management has become a buzz word in the BPM industry.

Social Business Process Management is about to integrating the processes your customers and employees perform in the social networks like Facebook and Twitter etc. into your company process landscape.

For example imagine your helpdesk using Facebook as part of the helpdesk process. But it goes even further. In the future your company will probably monitor the social medias and react proactively on events even before the customer has approached you. In the future I might make a tweet on Twitter telling that my ##%&* internet connection is yet again not working. My internet supplier catches the tweet and contacts me with a proposed solution. Sounds unlikely to happen? the majority of business process management companies don't think so.

Why is this prediction important to you? It is bacause your customers use of social medias will increase and they will expect to see you around.

What does this mean to you? First, it means that you need to think Social business processes into your business processes and you need to start thinking about how to start doing so. Second, it means that you need to consider your business processes as both seen from the inside-out and from the outside-in.

In the future business process consultants will need to ask them selves: What will our customers think of the processes they meet when interacting with us?

 

The main driver for business processes will be agility

Toady's businesses are facing more and more complex business environments and more and more unstable business environments. In other words the needs for changing your business processes will increase significantly in the future, Therefore, in the future, you will need processes that are easy to adapt to changes and you will need technology enabling you to adapt to rapidly changing changes.

Furthermore, the changes to business processes will be made by the business instead of IT. The business will be able to model new business changes and implement those without help from IT. To do this you will need BPMS like technology and business analysis skills among the business employees.

When I started in IT the business employees needed help when having to format a floppy disk or change printer cartridges - today, business employees are making simple databases, websites etc. in the future they will be analysing, designing and implementing business process changes themselves.

To do this you will need to implement IT systems that are enabling easy changes to business processes and business rules. Prepare for these kinds of demands!!

 

More Complex Business Processes

In the future the increase of complex processes will continue. According to a Mckinsey survey in average 41% of the business processes are complex interactions, 44% are routine actions and
only 15% are sequential interactions. Furthermore, in a business with increased business complexity more and more work will be performed by knowledge workers solving unstructured complex activities.

BAM - Business Activity Monitoring

Business Process Monitoring is about monitoring business events and let these events trigger other business processes in other IT systems and other parts of your organisation. It is like automating
the monitoring of the business. For example when we are busy in department A we know department B will be busy in a moment - you should monitor this event and act upon it. Or, if you monitor that your customers demand changes you can shift business processes to react on that knowledge.

I think BAM as a concept will be a hot buzz word.

 

To summarise; in the future social medias will interact with your business processes. You competitive edge will depend on how easy you can adapt to changes. In the future you will need fewer business process consultants to analyse your current business processes and more business process consultants to help your organisation getting more Business Process Mature and being able to monitor and change business processes themselves.

 

 

Implementing Business Process Management in Your Organisation

Gaining business value from implementing business process management in the organisation becomes more and more relevant for businesses trying to sharpen their competitive edge.

However, it is often a lot harder than it sounds. I have seen a lot of companies succeed and a lot of companies fail or - at least - not benefiting as much as intended.

One of the difficulties is to determine where to start.

I have tried to outline a short roadmap for, seen from my experience, succeeding with implementing business process management.

 

The overall roadmap to follow is:

• Determine your level
• Commence with a project to get you to the next maturity level

  

Determine your level:

 
1) Beginner

• Create a projectplan. Your effort should be captured in a projectplan otherwise you have no backup to your project. Remember to plan your initiatives so that it fits to your organisation. From my experience a sure path to failures is to commence with more tasks and changes than the organisation can absorb.
• Define what BPMN notation and method to use
• Determine BPM objectives. Always specify what to achieve and how to measure it.
• Develop an implementation roadmap. Start with one department or business unit. Define KPIs and get started. Remember after project closure to gather lessens learned and implement these lessons learned when approaching the next business unit - only by doing this you tailor the implementation to fit your organisation

 Tips:

• Get top management support (here your project plan comes in handy)
• Build a Business Process competence center. The Business Process Competence Center needs trained superusers who can support the organisation in BPM questions and guide the direction in new projects incorporation BPM.
• Establish a Business Process Repository. Soon after your business units uses BPM a lot of processes and process designs will be created. Be sure to have a place to store and keep track on the processes.
• Make sure that the BPM initiative is NOT just a great idea within the IT department
• Make it easy to start using BPM. Try to determine the minimum effort to do inorder to still think we are doing BPM
•  Training - the more the better

 Main benefit at this stage:

• Guide projects in using BPM
• Improved isolated processes (isolated to one business unit)
• Better requirement specifications can be produced

 

2) Intermediate

 Tips:

• At this stage you should establish a business process governance  model. You need to manage process changes otherwise your process analysis becomes outdated and useless.  
• At this stage you need to establish a method for continuously process improvements.

 Main benefit at this stage:

 

• Improved cross-units business processes
• Competitive advantage can be designed from process design
• Programs can be defined to capitalise on BPM initiatives

  

3) Advanced

 Tips:

•  At this stage you should be able to center business development around business processes. Being true process oriented
• All your processes should be able to identify process owners who are responsible for monitoring and suggest process enhancements

 

 Main benefit at this stage:

 

• Business Processes can be used to make strategic decisions

 

Process Governance

In the world of business process management several frameworks exist for ensuring a standard notation and a structure of models to use.

However, very few methods (outlining how to use the framework, when to use which parts of the framework etc.) exist. This leaves many of the projects without a clear and committed governance structure for the processes being specified. Unlike many project management methods, for example in PrinceII where project governance is a central part, the governance is most often missing in regards of the business processes. That is a huge disadvantage because it leads to unmanaged process documentation and business processes that are no longer being paied attention to.

Business processes do change - even after they have been reengineered and optimised. So, how do we keep track on those updates, document them and make sure they and being addressed in terms og process optimisation. The easy answer is: Point out a business process owner for each process and make her responsible for monitoring business process changes and for business process optimisation.

This works fine for simple business process landscapes. But, often the person being responsible for a process is the department manager responsible for the process in the first place and that
will lead to sub-optimisation of the business process.

Following this guideline can ensure a minimum degree of governance:

Establish a governance structure for your business processes and write the decision into the project plan where the business processes are part of the deliverables.It is fine if the governance structure is very simple, but it should answer:

a) Who reviews business process designs (not department managers but e.g. a process board)
b) Who can sign-off on a business process design (not department manager but e.g. a process board) and how is sign-off documented
c) Where are the business process designs documentation stored and how is it versioned (Configuration management). Consider a business process repository
d) Who can suggest business process changes
e) Who is responsible for maintaining the business process design documentation

 

Why is all this important? well, in todays IT environment the business process design generates competitive advantages and therefore the business processes are an assett and should be treated as an assett.