In the P4 framework the project is replaced by the development of a product or application version. The different designation should lead to more content related development project goals and not to goals that are more or less arbitrary, and sometimes even contradictory.
But what if the organization still “thinks” projects? Can’t we be agile then? If so, what prerequisites and constraints should then be considered? These questions shall be answered here.
First of all, we look at the structure of the organization above the projects. If it is still managed according to classical principles, the “agile” project will have a hard time. We must therefore take care of the following “transitions”:
- Fixed scope with predefined or “negotiated” dates >>> variable scope and iterative-incremental approach
- Annual budget planning >>> Adjustment to changing (project) portfolio planning, at least quarterly
- Annual planning of development projects >>> Adaptation to changing (project) portfolio planning, at least quarterly
- Too many projects running simultaneously >>> Focus of team members on one project and prioritization within the variable scope
- Almighty bosses >>> separation of powers and self-organized teams
Assuming that we have cleared the hurdle, let’s look at the different types of projects that are carried out in the organization:
- Organizational change projects
- Development of one or more new products
- Development of a platform on which new products are to be developed
- (Further) development of a new technology
- Development of a new product based on a platform
- Development of a new module for a platform
- Development of a new product based on one or more technologies
- Extension of an existing product by one or more functions
In previous projects, the different project types and goals were often defined into a single project, which made them very large. Also, such projects were only considered successful if all goals were achieved, which was often not possible at all due to the conflicting goals.
In P4, these different targets must be clearly separated and prioritized. This makes the projects smaller and allows for focused implementation.
How do agile projects work?
Project start
As with the development of product versions, a vision of the project is needed. The vision describes …
- the scope of the development, i.e. the goals and delivery objects, as mentioned in an isolated list estimated with business value
- the context, i.e. the environment of the product to be developed, its surrounding systems and their interfaces, its intended use, as well as the markets and the resulting norms and standards
- the most important stakeholders (including users and customers, as well as internal departments), i.e. the people who have an interest in the project
- Which main questions should the project answer? P4 uses Knowledge Gaps for that.
Project organisation
As far as these are not already defined and introduced by the P4 framework, further specifications must now be made:
- Which persons and roles are envisaged? In P4 these are the product owners, system engineers and scrum masters.
- When setting up the team, it is important to make sure that the clear majority of the team members are full-time team members. Specialists can participate as extended team members with more than 30%.
- If several teams are involved: How are these teams set up? What are the cooperation and supply relationships between the teams?
- Which existing teams have to collaborate on the project? How is this cooperation organized and do the teams have any free capacity?
- How are the teams organized internally in terms of time? So when do the various team events take place and who participates? (Team-Planning, Team-Sync, Extended-Team-Sync, Team-Refinement, Team-Review, Team-Retrospective)
- How do the teams organize themselves among themselves in terms of time? So when do the various project events take place and who takes part? (In P4: cluster planning, cluster sync, cluster definition, cluster review, cluster retrospective, and coordination meetings of POs, SEs and SMs)
It helps here if stable structures have already been created, e.g. by introducing P4 in the organization. Then these do not have to be set up, introduced, trained and improved for each new project! This makes organizations with a stable P4 structure much more effective and ultimately more efficient than organizations that introduce new structures for each project.
When looking at and comparing agile projects with stable agile teams that implement projects, several points stand out:
- The agile project organization can be customized. Thus, special characteristics of the project can be taken into account.
- Agile projects only pay off from a certain size onwards, as they have to invest the additional effort for their own project organization. However, this again results in the damaging tendency towards large projects.
Project execution
In project execution, agile projects hardly differ from the execution of product versions in stable teams. A common difficulty, however, is the varying degrees of utilization of specialized employees, who are completely overloaded in the project at certain times but have almost nothing to do at other times. Again, a possible but dangerous answer is to combine several projects.
Project end
“How nice it would be if the project team as a whole would simply get a new project. Then we could continue working together.” Quote from a disappointed project team member.
The end of the project is a similarly difficult phase as the beginning of the project. The main problem at the beginning of the project is to get the right project members into the project team at the right time. In most cases the bigger challenge is to start with too many people rather than too few.
At the end of the project, however, the main question is: When does the project really end? When the series production has started or the development has been handed over to operations or product maintenance? And what happens if problems arise with the new product and the project team is now scattered and working on other things? These are difficult questions, which in an emergency are often answered by “task forces”, which often makes the main problem worse (see “Task Forces: The Dark Side of Project Management“).
(picture from octadan on unsplash.com)
Next article: How to cope with predefined deadlines? | Back to FAQ | Home