Many companies handle projects for customers particularly efficiently and very well. The focus is on the customer and the service quality is excellent. In addition to projects for customers, companies also carry out internal projects. However, in contrast to customer projects, these are often very chaotic.
It is true to the motto: outside Hui – inside ugh. Staff units do not know what to do, internal projects are delayed up to 12 months or have stood still for years and nothing is moving. At the same time, however, external projects are still being carried out very successfully. The question now arises: What can agile program management look like internally? How can I be just as successful internally as externally.
In the following I would like to explain my idea and also show how the projects can be monitored (controlling) in a meaningful way. I assume that internal projects are always done alongside day-to-day business and that the goals of board members are vague for employees. So I want to solve the following questions:
- How can board members’ goals be translated into measures in a meaningful way?
- How can employees be drafted?
- How do we do it with a maximum of 1 FTE?
- How can we carry out internal projects without fixed internal resources (day-to-day business comes first)?
- How can we measure internal projects?
- How can we measure our strategy progress?
Step 1: quarterly planning
The first step is for the board to set goals. Often the goals of boards are seen as vague. Eg we improve the quality of service or we want to become faster. I think that’s OK and board members should no longer communicate. It is up to the employees to design the goals in a meaningful way.
My recommendation is therefore to collect 3-5 goals from the board in the first step per quarter. Now there is a full-time FTE which, together with the board members, creates very large program epics (P-Epic). This is a translation of the goals into software such as Jira (plug-in portfolio). The process step takes 8-16 hours per quarter. Examples are: improvement of service management or the introduction of an ITSM tool as a P-Epic.
Step 2: Conception of epics and involvement of employees
Now it goes to the 2nd step. Together with the program team (1 FTE), the department heads must name specific measures in the form of epics, which “pay off” for the respective goal. For example, we take measures 1, 2, 3, … to improve product quality. I recommend that each department head name 3 specific projects that he would like to implement and prioritize them according to 1,2,3.
Together with the program team and the department heads, these 3 measures per goal are presented to the board and approved. This happens within the first 14 days of the quarter. Thus, with 3 department heads, 9 major measures per quarter for the implementation of the strategy can be guaranteed. The department heads coordinate the measures with the respective employees. Thus, the inclusion and the possibility of design is given. Now it’s time to implement it.
Step 3: implementation
Now the 2.5 month implementation phase follows. On the one hand, the program team and department heads can continue to throw in new epics, and on the other hand, the board can flexibly throw in new topics. So that this is regulated: Change for free and Money for Nothing:
- Any epic not started can be exchanged for a new epic of equal value
- Every started epic can be exchanged for a new epic of equal value and costs the currently invested time + 20% of the hours (set-up time)
You will find that by doing this you are also in a way educating the board that changes are thought through and not bombed out all the time. The context switch is also compensated for with the 20% additional effort. In this way, you really show honestly which work flows into which tasks.
My tip for measuring work progress and building up pressure: hold a meeting every Wednesday. Each employee is allowed to talk for 90 seconds for each epic that is currently being processed. So you can go through 20 epics in 30 minutes. The regular status puts pressure behind the epics, creates transparency and clarifies questions.
The employees themselves are now busy working through the epics. After a quarter is over, a release train leaves. The so-called (agile) release trains are a metaphor. A train is never late – it leaves on time and takes everyone with it! Thus, all epics are presented to the board at the end of the quarter. No matter what the status is.
Step 4: new quarterly planning and agile controlling
Reporting (agile controlling) is now carried out. This reporting also helps to carry out the new quarterly planning. Goals can either be continued or new goals can be added. After step 4, you will start again in the next quarter at step 2. I would now like to explain agile controlling to you.
Agile controlling
Controlling is very simple in this case. On the one hand, you can book working time on the epics and also assign story points (internal currency) on the value of a story. I myself think that the following should flow into the story points of the Epic:
- Risk (1-5 points awarded the points in reverse – high risk: 1)
- Benefits for the company (1-5 points)
- Effort (1-5 points awarded the points conversely – high effort: 1)
- Merit (1-5 points)
- Now calculate the points. An epic can have a maximum of 20 points. Example: If an epic has a high benefit (5), little effort (5), good earnings (5) but a high risk (1) it is 16 points.
Based on these two figures, I can tell at the end of the day: How many hours have we invested in a goal of the Board of Management and have we achieved many points? Above all, the points help to see: are we really doing what is essential and important?
Example of the evaluation at the end of the quarter
I would like to give you another example. You can see in the picture below that I have two very vague targets. These are implemented through concrete epics. As a board member, you can now say that you have improved the quality of service for over 900 hours. You had two sub-goals and five specific projects.
You will also notice from the points that, especially in the point of service management, significantly more profitable epics than in point 2 have implemented technology framework. Maybe you should keep focusing on service management or Epic 4? You have to decide this now.
Reading tip: Agile controlling
Conclusion
It is often chaotic in internal project management or program management. Problems are unclear requirements and a misunderstanding of the strategy. For this reason, I propose an agile approach for internal program management. For this purpose, the objectives of the Board of Management are translated and measures are derived. These are implemented every quarter and supplied with the necessary delivery pressure through a release train. The progress is measured in hours and points. As a company, you can say exactly where the effort goes and how we implement a strategy.
[werbung] [fotolia]
