How to be Successful with the Process Design Team: Five Tips
Oct 2, 2014
Over the past years many organizations have been working with an Agile method for software development, providing the design team 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 five top tips to help 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.
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.
4. Make a framework for the conventions and concepts
The fourth tip involves making 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 regularly testing 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. It would be wise 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.
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 the above tips internally with their colleague process designers. For the individual designer, start communicating with the stakeholders. I have gained my experiences from working within several organizations and branches and would be delighted to hear your thoughts too.
