After graduation, my first job was at Kockums Computer Systems AB (KCS). Kockums was already using SAAB computers in the early 60’s, and continued doing so for many years. When the shipbuilding industry of Kockums was discontinued in the mid 80’s, as I began my career, the company was probably world leaders regarding the application of computers for production of huge ships.
The key to success for Kockums was the modeling tool developed in the 60’s, and then gradually improved. Actually, it is still used at shipyards worldwide with great results. Today the system is further developed by AVEVA, the owners of former KCS. Some of the competing firms have been enormous companies with a massive capacity, however their architecture of the software is incorrect. The achievements of Kockums were based on their point of view concerning the regulation of the production; producing with good preciseness and quality, keeping the price cost-effective. In contrast from the competitors, the boats weren’t outlined in a traditional manner. Instead, a model of the ship was built in the computer, from which plans were produced as required. An additional advantage with this system was the information concerning orders of material, when sheet metals should be burned, pipes bent etc. Competitors attempted copying the ideas, however their CAD/CAM systems were based on outlines, and consequently they never achieved the opportunities that were, and still are, available in the systems of Kockums. Below is a picture showing the complexity of these constructions:
Utilizing these ideas from KCS has been on my mind for quite some time. I’ve sketched and made prototypes on project management tools where the project is modelled, recognizing the benefits compared to MS Project or case management systems such as JIRA. Above all it reduces the needs for follow up meetings. The information is up-to.date rather than a week old as is the case when the material is collected manually. Furthermore it promotes transparency within the corporation. This tradition of modelling tools has become popular all over Malmö, and now a complete Agile Collaboration Tool (ACT) is available, providing exactly the benefits a modelling tool in theory generates compared to other architectures.
I’ve taken on the role of missioning for this tool, since I have a passion for making the work in projects with software more effective. The tool is especially interesting in combination with development of hardware, since the agile world within software must consider the manufacturing time of hardware. In collaboration with a number of individuals working with change process and education, I aspire to take Swedish project management within software one step further.
To enable management of larger projects in an agile manner, a framework supporting not only one or a few teams, as SCRUM does, is required. Several frameworks such as SAFe or less are available, however which process you use or if you’ve developed one on your own doesn’t really matter since we support you in adapting processes and the tool according to your wishes.
An example of some typical situations I, as a manager in a development company, would like support in are:
- One team is planning on delivering after the definite last date possible to enable a delivery of the release on time according to the roadmap.
- One team is delayed and must postpone a work package; How will this affect the other teams? I.e. which dependences I must take into consideration.
- How the teams are holding on compared to each other. If one team is ahead, some resources should probably be transferred to the team that is behind, or a work package can be assigned to the team ahead.
- So called “What if” analyses; What happens if I choose to deliver this feature earlier? WIll we manage? Moreover, what happens if I reduce/increase the capacity of a team? How will what affect the deliveries? What margin is there for scheduled releases? If a release or a SPRINT is brought forward, which work packages will not be completed?
In other words, the project management can set the framework for the project, while the teams are able to prioritize accordingly. As long as they don’t step outside the frame, they are free to handle on their own. In case any conflicts arise, they will be exposed by the tool, enabling the corporation to take care of them.
Some examples of how ACT presents the first two above:
Here, the product management notices that one team won’t be able to deliver in time for release R9:
Simultaneously the team receives a warning about not delivering according to the expectations of the roadmap:
One team has postponed a delivery, consequently another team is affected. Here the postponed team is able to see the effect on others:
Here the affected team can see that they are depending on something what will be delivered later than expected:
A difficulty in keeping project plans updated is gathering the information and revising the plans. Frequently, I’ve used MS project for planning, but when the project begins, I’ve gradually discarded the project plans since they weren’t helpful in my work. I prefer keeping things tidy, but I’m far too lazy to spend all the time that is required to keep the plans up-to-date.
Altogether, a useful tool should support in keeping the plans up-to-date. Above all, the status of different activities should only be noted once, and still be available and applicable everywhere. An integration of the project tool with the company’s case management system such as JIRA would probably be useful here. This provides ACT with continuously updated information about the status of different cases, giving the project management a clear view of the project in real time. Particularly, without detailed daily revising of everything happening in the corporation. The management and the developers are able to focus on strategic analyzes of inevitable arising problems together with development of software.
Hopefully I’ve managed to illustrate the functions of ACT and why I personally find this tool interesting.