English | EN In the Architecture Office #5: Explosions in work
Aug 11, 2014
Previously in the Architecture Practice: Chief architect Herbert Birchbranch (called Herb in the text) felt quite satisfied when the architecture service portfolio and next year’s budget was set. The service Concern Analysis became a hit, and the communication of the working model had worked out fine. Almost all different entities he had met were very positive.
From unstructured advices to service fulfilment
Before Herb entered the role as chief architect, the architecture practice was mainly active through architecture meetings and participation forums. No structured deliveries were done by the architects. The service portfolio, the communication of it and a more offensive way of taking position in different cases had turned things really upside down. The architecture practice had suddenly become a service organisation with expectations. And it has been an explosion in work!
A new problem came to surface
As per definition with the earlier way of working in mind, there were no useful tools in place to support the architecture practice. It was not only about managing the service delivery activities; the new way of working also drove production of documents. Another perspective that required tools support was the fact that the team was distributed. Support for collaboration was needed.
Herb checked around to see what possibilities were available. The answer was Jabber, Lync, SharePoint, G: and a project management tool. SharePoint could be used for the documents, but none of the actual tools were supporting the urgent needs of activity management. Herb started to get a headache. It was impossible to get an overview and control without spending a huge amount of time.
First attempt to solution
Suddenly one morning while drinking a cup of coffee, Herb remembered how the system development unit manager, Harry Olson, proudly talked about his digital Kanban board a month ago. Could that be something? Herb called Harry and asked if he could set up a Kanban board for the architecture team. “I will fix that,” Harry said, “but it will take a few days.” A week later Herb was adding the actual actions into the architecture practice Kanban board. At the next architects meeting Herb introduced the Kanban board and assigned his project office architect Roberto to manage the board further on. The complementing directive was that everything we do has to be put on the board, and that it shall be followed-up weekly in an architecture office meeting taking place after the project office meeting.
Finally Herb got in control of the teams work again and it became possible to prioritize.
The board, though, brought a new concern to the surface. The architecture team had too many actions on-going, which in turn lead to a very poor throughput. Too few actions got finalized.
Herb decided that the way of working with actions had to be changed.
After a discussion meeting with the team a new way of using the board was decided. It was based on a couple of rules for the way of working:
- Minimize the number of on-going activities
- Structure the backlog content into different domains
- All activities shall have a demanded end date
- All activities shall have one responsible
- Actual status is written into the Kanban card as a note
- If related to a project office order, set the reference number in the action header
- Attach documents related to the delivery into the Kanban card
There was also a possibility to use color coding for the actions, or in other terms, to categorize them. Herb decided to use the following categories to start with:
Architecture Start Assurance is related to the same architecture service
Concern is related to the architecture service Concern Analysis
Assessment could be any assessment ordered via the project office
Task is usually an internal architecture office task
Project is architecture capacity dedicated to a project
Participation is participation in any forum as an architect
Delivery object, may sound strange, but it relates to deliveries that are not architecture or output from an architecture service.
There are also attributes available for an activity. Some are graphically depicted in the overview. The following are used from start.
Attributes on an activity
- Title / Headline
- Initials of the Responsible (“CB” in this case).
- Date (if demanded ready date is set)
- Attachment (if there is one or more files attached )
- Exclamation mark – Critical priority
- Triangle in circle – High priority
Herb was aware that this is the starting set-up. Evaluations have to be done continuously to trim the use of the Kanban board.
Conclusions
When an architecture practice starts to work with its “customers” with higher seriousness and based on a structured service portfolio, the result is likely a lot of tasks, tougher pressure, and higher demand. This is good. It is very good. Because it is proof that the architecture practice has got acceptance as a valuable resource, as well as the right playfield has been set. With the business demand in the back, the problem with lack of resources is just pleasant. Imagine the opposite.
The architecture practice always will suffer from lack of capacity. To introduce more lean oriented ways of working is one way of taking care of the issue. Use a Kanban board. It suits architecture work well and keeps the administration to a moderate level. Just keep the number of on-going assigned actions to a minimum. The rest shall be parked in the backlog.
A tool is just a tool. The way of working is still the most important. Use of tools, though, may act as a catalyst to develop the way of working.
To be continued…
About the author
