Many employees are complaining about their jobs. They have to spend too much time on tasks they hate and cannot spend enough time on tasks they love to do. So to increase employee satisfaction it is very important to get rid of those tasks that are making employees unhappy.

In most modern offices employees have to deal with tasks they perceive as bureaucratic, mind numbing or inefficient. Instead of helping customers or creating new products they are wasting their talents on pushing paperwork, endless email chains, scraping information from numerous old systems, waiting for approvals and waiting for answers to questions asked a long time ago.

Read more: Improving Employee Satisfaction with Business Process Management Systems

Pega offers an interesting set of methods and tooling for directly capturing requirements and specifications into the system, called Directly Capture Objectives or DCO. The core of DCO is having DCO sessions where business and IT delegates work out the process flows and draft UI together. From practice I’ve seen that it's not always easy to make it work on the short run. Expectations of the results can be unrealistic and it takes some time for people to get used to the DCO way of working. But don't lose hope because when it starts working, it really gives a good vibe to your BPM project. This blog explains three do's and don'ts for working with DCO.

Read more: Six Do's and Don'ts for Directly Capturing Objectives

In today's market there are more than a few Business Process Management Suites (BPMS). Each has their strengths and weaknesses.

Pega and OpenText (formerly known as Cordys) are two of those Business Process Management Systems, which can be used to model and execute (business) processes. The kind of functionality is the same for both platforms. Therefore, there is a lot of overlap between of the platforms, but as with all similar tooling there are also differences.

Read more: Comparing BPMS Tools: Pega vs. OpenText

During Model-Driven Development projects the question often arises as to why we should document the requirements and specifications. As business owners easily understand the model used during model driven development, it diminishes miscommunication between business and IT professionals. Therefore it could seem sufficient that the product owner and system architect only have to sit together to build a quick POC that will be extended later by the project team.

Read more: To What Extent Are Requirements and Specifications Useful?

In many application development projects it is a recurring problem: The application is documented both functionally and technically inadequate. As a result, the software is difficult to transfer and maintain. Modern development tools try to prevent this problem by keeping software and documentation together in one environment.

Read more: Reduce Transfer Problems with Self-documented Applications

Page 4 of 5