EA Voices

Reliability Centered Maintenance (RCM), Is a must organ […]

How to be successful with the process design team? Five tips!

Over the past years many organizations have been working with an Agile method for software development, providing the design and development team with a particularly important role. Within several projects in which I was involved I had the chance to experience this from up close. In this blog I would like to share with you my experiences in working with the five top tips helping a design team efficiently and effectively perform within an Agile environment.

1. Process design as a solid base

The first tip is all about creating a solid, high-quality base. This base will create a certain structure throughout the entire design process and will provide the scope of the process design. Next question on your mind now: But what does this base actually create? It is the key that the different stakeholders are familiar with the process design and are aware of its content. The process designer should bear in mind the possibility of minor adaptations taking place during the design track in the process design. Smaller parts of the larger whole are being developed. Because  there is a framework present that gives guidelines and scope, a solid and flexible base has been designed. From which any adaptations to the process model can relatively easily be completed.

2. Use a complete and solid data model

The second tip involves adding structure to the data present in the project, domain, subject area or department. Two data models can be distinguished, the first of which is the conceptual data model (CDM). The CDM contains all pieces of data (entities) present within the project, domain, subject area or department and any information on their mutual relationships. The different entities consist of attributes representing exactly which elements should be present within each entity. For example, which data (attributes) are required in an invoice (entity). Here we think of the amount, invoice number, name and address information, etc. The different attributes should moreover be further explored, where per attribute the following information should be specified.

• Definition: what exactly is the attribute.
• Data type: which type of data is being used (for example, an amount or text).
• Range of values: the attribute needs further specification: which elements make up the attribute (for example, a zip code will contain both digits as well as letters).

​The second data model we distinguish is the process data model (PDM). The PDM contains the data applicable to a specific process. The PDM is a minor building block of the much larger CDM. The data models act as input for the development team, providing them with a clear image of what it is they are developing. That is why it is the developer’s responsibility to provide the development team with very clear specifications (the range of values).

3. Collaboration with stakeholders

The third tip is about the collaboration with the most important stakeholders in the eyes of the design team. An important stakeholder for the design team is the architect. The architect is able to communicate which business and work processes can be distinguished and which requirements/parameters should be met. It is the architect who can clearly present the scope and the impact on the organization. The second important stakeholder is the development team. Make sure you as the designer are in direct contact with the developer, who can ideally provide you with further clarifying input, if needed. Other important stakeholders are the test team and management team. Invite the stakeholders to get involved in the design track and keep the lines of communication short. This will ensure clear communication with as few as possible unnecessary disruptions in the realization process. All too often, I see designers hand over their designs to the development team without any form of communication. This results in a portion of the idea being realized, but not the full package. By getting the developer involved early on and aiming for a better collaboration, he/she will have a much better understanding of what it is you’d like to see happen. In the user story specification of what needs to be developed is much more straightforward.

Working as design team!

 

4. Make a framework for the conventions and concepts

The fourth tip involves the making of clear arrangements around the process conventions and concepts. Within the software development team, it is key that the different members clearly decide on the specific criteria to be met by the process model and what the model should look like. Those agreements should ideally be compiled in a convention document. Many organizations do have such a convention document in circulation. It is expected of the design team to apply these conventions in the modeling of the process designs. Just as important is it for you to regularly test your process model against the agreed conventions. Such a test will ensure the consistent implementation of the conventions, moreover allowing the stakeholders to easily recognize and understand the models. These are familiar concepts to them, after all. Which brings us to the wording used within the project and process design. The misinterpretation of certain concepts could potentially be the cause of much hassle. Wise would be to draw up a list of commonly used terms. Make sure an up-to-date list regularly finds its way to the stakeholders. These clear and unambiguous process conventions and terminology list can only improve the collaboration between the design team and its stakeholders.

5. Document the most essential documentation

The fifth and last tip covers the documenting of all documentation being developed within the process design. In this tip, I do not talk about all the documentation in de design track but only about the documentation from the process design. In my experience, Agile and Scrum environments can do much better in documenting the documentation from a process design. This is often a result of the lack of time provided to organize the documentation for a process model because of the speed with which development is announced. Even afterwards, the documentation is rarely brought up to date, as new projects have already started. Any realized projects are unfortunately minimally documented. If management would want to review any of these, this simply would not be possible due to a lack of documentation. From this point of view, one could argue for the importance of keeping relevant documentation up to date and to schedule the time to complete this. As a designer, regularly check if all documentation is complete and if needed, request the extra time to take care of this.

Documentation in a design track!

 

Hopefully this has given you more insight into the success of a design team. My tips are intended to help pinpoint where exactly things stray within a design team, and to guide any designer in preventing such situations. I will recommend the designers to discuss above tips internal with their colleague process designers. For the individual designer, start communicate with the stakeholders. It is easy to realize because you can contact the stakeholders easily. I have gained my experiences from working within several organizations and branches and would be delighted to hear your thoughts too.