My 2nd book What Drives Quality is available on Amazon, in my webshop, and in all other major bookstores.
The series on What Drives Quality describes both technical activities and supporting quality activities. There are technical articles which dive into Requirements, Architecture and Design, Coding, Reviews and Inspection, and Testing. Other articles explore what Senior Management and Operational Management do to ensure that quality software products are delivered to customers. This article describes how Project Management drives quality.
Understanding what drives quality enables you to take action before problems actually occur, saving time and money.
With project management I mean managing of projects and programs that include software development and delivery. This can be waterfall projects, RUP, or Agile project Management; the basic principles of project management and their contribution towards software quality is needed for all these kinds of projects.
Quality by Project Management
Project managers can use specific project management methods or certifications (eg. PRINCE2, PMI or IPMA), these methods describe the quality activities that should be performed. Also the CMMI includes process areas that cover project management and describes quality activities that are typically performed in projects.
Factors that drive Quality by Project Management are:
- Decision Making Capability – The ability to balance quality, time, cost, and functionality and to make timely decisions that involve the right people. Also to assure that decisions are communicated and that the work is followed up to completion.
- Project Portfolio Management – Planning and tracking of the set of projects, including project steering groups and all decisions made to start, continue, cancel, and conclude the project.
- Project Management Capability – Skill and experience level of project managers.
- Risk Management Process Capability – Awareness of project risks, the maturity of the process, and the capability of managing risks.
- Planning Capability – The ability to estimate, plan, and track projects with respect to the quality of the delivered product.
- Scope Stability – Impact of major changes in the projects (e.g., those related to stability of the products to be developed), the development teams involved in the projects, and major changes in project funding or delivery dates. These changes are often related to changes in the product road map.
- Schedule Pressure – The way deadlines are used to put pressure on projects and people to deliver on time.
- Operational Overview and Insight – Insight into the status of ongoing projects (e.g., processes used, documents delivered, quality of the documents).
- Operational Line Management – Activities done by department managers in their role as responsible for the short term activities.
- Project Management Process Adherence – Checks (e.g., audits or assessments) to determine whether the baselined processes are being followed and if they are effective and efficient.
Decision Making Capability
Project Managers are expected to take decisions that are needed for projects to deliver and meets its goals. This can be decisions about what to do, when to do it or how to do it. Depending on the project management method that is used and how the project is steered and monitored, there can be big differences in which decisions are taken by the project manager, and which are taken by members of the project team, or by stakeholders.
For instance, in an agile project, the content of each sprint is decided in the planning game. The Product Owner and team discuss the User Stories, estimate the work involved, and decide which ones will be included. The planning game should decide about the product quality that is required, since this can have much impact on the work that needs to be done. Aspects of quality are the knowledge and skills that are needed to develop the software, the quality activities that need to be done (eg. pair programming, reviews or testing) and the process that will be used to do the work. Decisions can either be documented on the Scrum board, or in the Definition of Done (DoD). Finally, agile retrospectives can be used to look back on decisions that were taken in the planning game and stand-ups, and to continuously improve the capabilities of the agile team to manage their work.
Do we still need project managers to manage projects with agile teams? Yes, but their role will be different. Project managers can for instance organize the coordination between the project teams (eg. with a scrum-of-scrums), to ensure that the sub products can be integrated and delivered. In larger projects they will do the delivery planning, to ensure that project deliveries are aligned with product road maps. And they have to align the project with all the stakeholders, like project sponsors, line managers, and product managers, where this is not done by the Product Owner. In the end, a project manager is also responsible for steering product quality in agile teams, and for the reporting of his/her agile project. My opinion is that there is still a need for project managers in agile, where they support the primary planning mechanisms from agile methods like Scrum, DAD or SAFe.
Risk Management
The quality of the software products is related to the way that risks are managed in projects. Product quality risks should be identified early and continuously, and actions taken to either reduce that change that the risk occurs, or mitigate quality impact.
In agile, User Stories that pose a high risk are usually done as early as possible in the project. It is better to deal with risks early, while there is still room to deal with them. Spikes are a great way to deal with risks in projects as early as possible. They decrease project disturbances, and help agile teams and product owners to get quick feedback about product possibilities. To reduce risks and improve quality, agile teams should develop their capabilities to deliver code with high quality.
Schedule Pressure
Several good books have been written on managing time and people on projects, like The Mythical Man Month from Fred Brooks, Peopleware from Tom DeMarco and Tim Lister and Managing for Happiness by Jurgen Appelo. They make it very clear that (project and line) managers should carefully manage teams, and prevent that professionals are overloaded with work. My experience is that keeping teams composition stable enables team members to learn and improve continuously. Also XP promotes a Core Practice “40 hour workweek”, which aims to reduce pressure on team members to prevent them from making mistakes that result in less quality.
Why do project managers put time pressure on their teams? I don’t know, and it still surprises me, so I can only guess at their reasons to do it. Maybe because they think that putting pressure on people makes them more productive? That teams need deadlines to come up with results? They might see it as bargaining, where they want to find the optimum amount of work to be delivered within a time frame? If you know what drives project managers to put pressure on their teams, please react to this post, and let me know!
Summing up, there are lot’s of good reasons for project managers to reduce schedule pressure, to reduce quality risks with products that are developed.
Project Management drives quality
Project managers can drive quality by taking decisions that enable the project team to professionally develop software, and by establishing a structure and environment where the team can deliver quality products and services in an efficient way. And by taking and communicating decisions timely so that professionals know what has been agreed with the project stakeholders.
There’s my book on what drives quality which helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money!
Together with Senior Management and Operational Management, Project Management drives professionals to deliver high quality products, on time and within budget, which meet their quality goals and satisfy the needs of their customers and stakeholders.
(This blog was published Dec 15 2011 and updated Oct 18 2013: revised and info added on managing quality in Agile/Scrum projects and updated Feb 15 2017: revised and updated to new developments in project management and quality)