Lean PPM – step 12: Documentation consumer type 2: project leads, business analysts, (requirements and software) engineers, or likewise folks

Prolbares (= project leads, business analyst and requirements engineers) express a lot more needs in documentation. Prolbares are around on all abstraction levels of requirements (see the requirements abstraction model RAM by Tony Gorschek and Claas Wohlin). Prolbares work from business goals, high level business processes down to tiny technical details. Prolbares are involved in the full lifecycle of designing and implementing desired changes (see “The life cycle of an initiative”). In the design process of a change they are responsible to elicitate, design, communicate, consolidate and confirm requirements of a change. In this context “change” is anything from a small continuous improvement in an existing system to a discontinuous innovation in form of a new product or service.

In respect if documentation, Prolbares are like chameleons. Some like to write novels, some hate writing any documentation, some like modeling, some prefer to paint pictures; some are more user experience oriented, some rather are technicians; some feel comfortable on the abstract levels of requirements like business goals, processes and features, some love tiny details…

Naturally the requirements of Prolbares for documentation are magnifold:

• In the initial part of the lifecycle of a change they have an interest about the current situation. Source code and acceptance tests are a good source of the current state of a piece of software – but unluckily, as mentioned in my last blog – this is often only part of the truth. Manual and organizational procedures do not have a source code. Documentation could be treated as the source code of a manual and organizational procedure.
• Prolbares consume and create many artifacts and share these with her team(s) like meeting notes, requirements specifications, prototypes, decisions, technical description, whatever is needed in the refinement of intiatives, epics and user stories.  Most of this is waste when the change is done. Most of it, but not all. Some pieces out of this huge amount of information is valuable for the first step – to remind on the current situation any time in the future when the next change is in the road.
• Because of the chameleon alike nature, finding anything that suits all Prolbares is like finding the holy grail. So we had to find options that satisfy the majority of the Prolbares.

Prolbares are hard to place within an organization. Reason is that Prolbares typically are not full time members in any team. If integrated into the IT organization (i.e. Scrum teams) they spent 50% of their time with stakeholders and business. If integrated into business, they spent 50% of their time with IT, and – if not – they loose contact to IT, what results in defects in the quality of requirements (conversation, confirmation, feedback loops). At digitec Galaxus business analysts are our Product Owners in the Scrum teams. 

If Prolbares act positive in an organization, they care for the whole (optimizing the system and not preferring a specific department). They act as mediator, moderator, translator between business and IT to balance needs and wishes. They support ideas to become visible; mature ideas into change projects and finally towards real implemented (continuous or discontinuous) innovations together with all involved departments, subject matter experts, external partners, management and whoever has stakes in the change.

This is the reason Prolbares typically have an interest on a higher amount of documentation than all other involved persons and job profiles in an organization. A good Prolbare want to understand the problem under discussion herself. So the write a part of the documentation for themselves. Then they use documented requirements to solve different views and conflicts between stakeholders in the design phase of a change project. Additional they try to create a documentation that best suites all stakeholder in documentation (from executive managers to engineers and technical experts). 

Unluckily often the documentation policies, structures and tools in an organization are not defined in a way to support Prolbares to ease their job. The results we encounter in many organizations. To many documentation; documentation that does not satisfy the needs of consumers; documentation that does not allow to search and find the requested piece of information to successfully work on a piece of work.

In my personal perception to identify an appropriate structure and tool support for this relevant part of documentation is the most critical point. In fact this is the part to support the activities of business analysis, requirements engineering and design in respect of the creation of required documentation.