All About Requirements

Inputs from Danish Project Management Symposium 2013

 

 

Just arrived back home from Danish Project Management Symposium 2013 where I was speaker in one of the seminars.

Here is a short heads-up on some of the interesting inputs from the project management world with relevans for Business Analysts:

The organisational value of the project will in the future be something that will be owned, managed, and controlled by the business and it will evolve throughout the entire project life cycle. Today, in many project management methodologies, the value of the project is determined at project start, fixed in business case, project charter and the like - and is rarely updated. That is about to change. It is difficult to identify all project benefits up front, and the business must continuously evaluate and monitor if the project benefits are the desired ones and if the project is on track in order to reach those benefits. For the business analyst it means that the project value/benefits will be changing, and that it is ok to identify benefits as the project evolves. It also means that the benefits identified by the business analyst can now be addressed directly to the business and not risk simply being ignored by a project manager more keen on just delivering the deliverables identified at project start.

 

The managing effort will get more attention in the future than the focus on methodologies and models. It will have more relevance to get the right think done, involve the right people, get the most value out of your team than following and mastering a specific methodology.

 

The projects are getting more and more complex, and the projects are continuously under time pressure and budget pressure. Therefore the transaction costs must be lowered. There are no longer time and energy left to micro-plan, micro-manage and follow methodologies just of the sake of the methodology. You need ways to produce outputs fast. You need to produce outputs without having to be managed in details by a manager - you have to be able to think and work on your own.

Expanding the Cloud – The Amazon Simple Workflow Service - All Things Distributed

Today AWS launched an exciting new service for developers: the Amazon Simple Workflow Service. Amazon SWF is an orchestration service for building scalable distributed applications. Often an application consists of several different tasks to be performed in particular sequence driven by a set of dynamic conditions. Amazon SWF makes it very easy for developers to architect and implement these tasks, run them in the cloud or on premise and coordinate their flow. Amazon SWF manages the execution flow such that the tasks are load balanced across the registered workers, that inter-task dependencies are respected, that concurrency is handled appropriately and that child workflows are executed.

A growing number of applications are relying on asynchronous and distributed processing, with scalability of the application as the primary motivation. By designing autonomous distributed components, developers get the flexibility to deploy and scale out parts of the application independently as load increases. The asynchronous and distributed model has the benefits of loose coupling and selective scalability, but it also creates new challenges. Application developers must coordinate multiple distributed components to get the desired results. They must deal with the increased latency and unreliability inherent in remote communication. Components may take extended periods of time to complete tasks, requests may fail and errors originating from remote systems must be handled. Today, to accomplish this, developers are forced to write complicated infrastructure that typically involves message queues and databases along with complex logic to synchronize them. All this ‘plumbing’ is extraneous to business logic and makes the application code unnecessarily complicated and hard to maintain.

via www.allthingsdistributed.com

Amazons workflow service. New approach for developers? The business process automation is more often a main driver...

Will Business Analysts Be Out of Work When Introducing Automated Business Process Discovery

When optimising business processes or analysing business processes in order to produce a business oriented requirements specification, you need to analyse and produce a process map showing the as-is process situation. in order to do that you probably conduct interviews with stakeholders, read documentation, facilitate workshops and so on. As we all know that can be a time consuming task.

 

Why not let a robot do the hard work and produce the process map for you?

 

The answer to this dream is Automated Business Process Discovery, which is an automated approach to create a business process model. In short, you let an IT system analyse your data (anyone saying Big Data and BPM?) for instance audit trails, message systems, transactional systems, databases, integrations, service busses etc. The ABPD system then looks for patterns in your data and the output is process models created from scratch.

 

Advantages are, among others:

 

1) The processes found and modelled are the processes actually processed. How often haven't we documented the processes the business thinks (or wish) they have and not the process they actually are having?

 

2) Inter-department / inter-organisational touch points are included in the process model and those are often hard to document correct

 

3) Bottleneck analysis can be analysed on real life data

 

4) The events and handshakes between systems are analysed and documented

 

 

Will the business consultants all be out of work then?

 

No, I don't see that happening. What I do see is that in the near future we will start using ABPD as a tool for speeding up the process mapping task. I say "in the near future" because very few companies uses ABPD at the moment. When I say we will not all be out of work it is because:

 

1) ABPD only captures the structured automated processes. The processes not automated you still need to discover yourself.

 

2) ABPD gives you a button-up approach to process modelling while traditional BPM techniques gives you a top-down approach. My guess is that you need both approaches.

 

3) Grouping of the user interactions is still needed

 

4) Documenting the formal process and not the process that happens to be processed still needs manual documentation

 

 

At the end of the day we will use ABPD for accelerating process modelling, not for getting rid of business process analysts.

 

Funf - Open Sensing Framework is That Part of Future BPM

Funf | Open Sensing Framework. is a very interesting framework that in it's own words "...is an extensible sensing and data processing framework for mobile devices, developed at the MIT Media Lab. The core concept is to provide an open source, reusable set of functionalities, enabling the collection, uploading, and configuration of a wide range of data types."

 

The interesting part is that it opens up for gathering all sorts of data - movement and communication. 

 

It then struck me; this trend will be part of what can be game changers for the BPM environment in the future. A trend in BPM that is already very present is the need to be faster in adopting new/changed business rules and business processes - to maintain the competitive edge - to survive.

 

In the future key employees and management will be monitored. Even competitors will be monitored. Key influencers from the industry will be monitored.

 

BPM teams will be required to analyse and react on the data gathered. And do it fast.

 

BPM teams will start analysing and preparing consequense assessments.

 

I think this might be something that can have impact on BPM in the future.

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. 

 

 

Business Requirements Documentation Trends - Just Some Thoughts

Just some thoughts on documentation needs and requirements; According to Copenhagen Institute for Futures Studies a trend is an ever increasing need for documentation.

It is a trend I also see becoming more and more real. I think of documentation in the sense of documenting software requirements, business rules, procedures, etc.

One of the reasons why the need for documentation increases is probably that the business domain becomes more and more complex, and therefore increases the need to document how the business requirements are structured and implemented. Furthermore there is a trend in the need for business requirement agility.

In order to compete businesses need to know (document) their business requirements and be able to change those requirements and implement the changes quickly – competitive businesses need to react fast to changes in their business domain.

 

 

 

So, two business requirements trends are present here: the need for more (better) documentation and the need to react fast on changes to the business requirements.

Documenting business requirements can be time consuming, especially if the business requirements and/or the business domain are very complex. Changing and implementing business requirements can be time consuming as well - especially if changing and implementing business requirement changes involves following an inefficient government process.

 

The reacting time for changing business requirements, as well as documenting business requirements, needs to be fast. There is a gap.

 

A trend in the business analysis area, as a consequence of the businesses requiring more documentation and faster change implementation, is:

 

1) The government process around changing and implementing business requirements changes needs to be lean.

At least the government process around business requirements needs to be optimised. Some of the initiatives I see in order to design a lean government process are implementing BPMS systems enabling the business people to change, implement, and document business rules themselves, without involving IT.

 

2) The business requirements needs to be structured in a way, not only sufficient for the initial implementation, but also sufficient for the ongoing changes