How Project Management drives Software Quality

Many methods for product quality improvement start by investigating the problems, and then working their way back to the point where the problem started. For instance audits and Root Cause Analysis work this way. But what if you could prevent problems from happening, by building an understanding what drives quality, thus enabling to take action before problems actually occur?

The series on “What Drives Quality” describes both technical activities and supporting quality activities. Previous articles explored 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.

An earlier version of this article has been published on BenLinders.com as What Drives Quality: Project Management. There is also an eBook available for download: What Drives Quality. This book explores software quality practices throughout the full application lifecycle.

 Managing Projects

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.

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 the quality activities that are typically performed in projects.

Factors that drive Quality by Project Management are:

1. 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.
2. 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.
3. Project Management Capability – Skill and experience level of project managers.
4. Risk Management Process Capability – Awareness of project risks, the maturity of the process, and the capability of managing risks.
5. Planning Capability – The ability to estimate, plan, and track projects with respect to the quality of the delivered product.
6. 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 roadmap.
7. Schedule Pressure – The way deadlines are used to put pressure on projects and people to deliver on time.
8. Operational Overview and Insight – Insight into the status of ongoing projects (e.g., processes used, documents delivered, quality of the documents).
9. Operational Line Management – Activities done by department managers in their role as responsible for the short term activities.
10. 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 project 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 must decide about 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 neededto develop the software, the quality activities that need to be done (eg. pair programming, reviews ortesting) 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). 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 projectmanagers to manage projects with agile teams? Yes, but their role will be different. Project managers can for instance organize the coördination between the project teams (eg. with a scrum-of-scrums), to ensure that the subproducts can be integrated and delicered. In larger projects they will do the delivery planning, to ensure that project deliveries are aligned with product roadmaps. 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.

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 shoulddevelop 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 and Peopleware from Tom DeMarco and Tim Lister. 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 team 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. Why it is still done (too) often surprises me.

Conclusions

Project Management can drive quality. By taking decisions that enable the project team to 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. Together with Senior Management, Operational Management and Process Management, Project Management drives professionals to deliver high quality products, on time and within budget, which meet their quality goals.

Veel methodes voor productkwaliteit verbetering beginnen bij het onderzoeken van de problemen, om vervolgens terug te werken naar het punt waar het probleem begon. Zo werken bijvoorbeeld audits en Root Cause Analyses. Maar wat nou als je problemen kan voorkomen door het opzetten van een verstandhouding die de kwaliteit stimuleert, en er zo voor zorgt dat er actie ondernomen wordt voordat het probleem echt optreedt?

De serie “What drives Quality” beschrijft zowel de technische activiteiten, als de ondersteunende kwaliteitsactiviteiten. Eerdere artikelen bekeken wat Senior Management en Operational Management doen om te zorgen dat kwaliteitssoftwareproducten worden geleverd aan klanten. Dit artikel beschrijft hoe Projectmanagement kwaliteit stimuleert.

Begrijpen wat kwaliteit stimuleert geeft je de mogelijkheid actie te ondernemen wanneer problemen daadwerkelijk optreden, wat geld en tijd bespaart.

Een eerdere versie van dit artikel is gepubliceerd op BenLinders.com als What Drives Quality: Project Management. Er is ook een eBook beschikbaar: What drives Quality. Dit boek bekijkt softwarekwaliteitstoepassingen vanaf begin tot eind.

Projecten Managen

Met projectmanagement bedoel ik het managen van projecten en programma’s die softwareontwikkeling en -aflevering omvatten. Dit kunnen watervalmethodes, RUP, of Agile projectmanagement zijn; de basisprincipes van projectmanagement en hun toevoeging aan softwarekwaliteit zijn nodig in al deze projectvormen.

Projectmanagers kunnen specifieke projectmanagementmethodes of –certificeringen (bijv. PRINCE2, PMI of IPMA) gebruiken. Deze methodes beschrijven de kwaliteitsactiviteiten die uitgevoerd zouden moeten worden. Ook de CMMI bevat procesgebieden die projectmanagement dekken en de kwaliteitsactiviteiten die vooral in projecten uitgevoerd worden.

Factoren die kwaliteit stimuleren door projectmanagement zijn:

1. Besluitvormend vermogen – het vermogen om een balans te vinden tussen kwaliteit, tijd, kosten en functionaliteit, en om tijdige beslissingen te maken met betrekking tot de juiste personen. Ook om zeker te stellen dat beslissingen gecommuniceerd worden en dat het werk vervolgd wordt tot het afgerond is.
2. Projectportfoliobeheer – Het plannen en nalopen van een stel projecten, zoals projectsturingsgroepen en zorgen dat alle besluiten die in het begin gemaakt zijn beginnen, doorlopen, afgebroken worden en het project concluderen.
3. Projectmanagementvermogen – Vaardigheid en ervaringsniveau van projectmanagers.
4. Risicomanagementvermogen – Bewust zijn van projectrisico’s, de ontwikkeling van het proces en het vermogen om risico’s te managen.
5. Plannend vermogen – Het vermogen om te schatten, plannen en nalopen van projecten met het oog op de kwaliteit van het af te leveren product.
6. Scopestabiliteit – Impact van grote veranderingen in projecten (bijv. gerelateerd aan de stabiliteit van de producten die ontwikkeld worden), de ontwikkelingsteams die bij de projecten betrokken zijn en grote veranderingen in projectfinanciering of afleverdata. Deze veranderingen zijn vaak gerelateerd aan veranderingen in het stappenplan van het product.
7. Planningsdruk – De manier waarop deadlines gebruikt worden om druk zet op de projecten en op de mensen voor het op tijd afleveren hiervan.
8. Operationeel overzicht en inzicht – Inzicht in de status van lopende projecten (bijv. processen die gebruikt worden, afgeleverde documenten, kwaliteit van die documenten).
9. Operationele lijnbeheer – Activiteiten die gedaan worden door afdelingshoofden in hun rol als verantwoordelijke voor activiteiten op korte termijn.

10. Projectmanagement adherente processen – Controles (bijv. audits of assessments) om vast te stellen of de basisprocessen gevolg worden en of ze effectief en efficiënt zijn.

Besluitvormend vermogen

Van projectmanagers wordt verwacht dat ze beslissingen maken die benodigd zijn om het project te laten afleveren en z’n doelen te bereiken. Dit kunnen beslissingen zijn over wat er gedaan moet worden, wanneer het gedaan moet worden of hoe het gedaan moet worden. Afhankelijk van de projectmanagementmethode die gebruikt word en hoe het project gemonitord en gestuurd wordt, kunnen er grote verschillen zijn in welke besluiten genomen worden door de projectmanager en welke door leden van het projectteam of door aandeelhouders.

Bijvoorbeeld, in een agile project wordt de inhoudt van elke print besloten in het planningsspel. De producteigenaar en het team bespreken de gebruikersverhalen, schatten het benodigde werk in en besluiten welke gebruikt worden. Het planningsspel moet besluiten over de productkwaliteit die benodigd is, aangezien dit veel impact kan hebben op het werk dat gedaan moet worden. Aspecten van kwaliteit zijn de kennis en vaardigheden die benodigd zijn om de software te ontwikkelen, de kwaliteitsactiviteiten die gedaan moeten worden (bijv. pair programmeren, reviews of testen) en de processen die gebruikt worden om het werk te doen.

Besluiten kunnen gedocumenteerd worden op het scrumbord, of in de Definition of Done (DoD). Terugkoppelingen kunnen gebruikt worden om terug te kijken op besluiten die gemaakt zijn in het planningsspel en om continue het vermogen van het agile team te verbeteren om hun werk te beheren.

Hebben we nog projectmanagers nodig om agile teams te leiden? Ja, maar hun rol zal anders zijn. Projectmanagers kunnen bijvoorbeeld de coordinatie tussen de projectteams organiseren (bijv. met scrum van scrums), om te verzekeren dat de sub-producten geïntegreerd en  afgeleverd kunnen worden. In grotere projecten zullen zij de afleveringsplanning doen om er zeker van te zijn dat projectafleveringen afgestemd zijn met de stappenplannen. Ook moeten ze de projecten afstemmen met de aandeelhouders, zoals projectsponsoren, lijnmanagers en productmanagers, als dit niet gedaan wordt door de producteigenaar.

Uiteindelijk is de projectmanager ook verantwoordelijk voor het sturen van productkwaliteit in agile teams, en voor het rapporteren van zijn/haar agile project. Mijn mening is dat er nog steeds projectmanagers nodig zijn in agile, waar ze de primaire planningsmechanismes  ondersteunen in agile methodes zoals Scrum.

Risicomanagement

De kwaliteit van de softwareproducten is gerelateerd aan de manier waarop risico’s beheerd worden in projecten. Productkwaliteitsrisico’s moeten vroeg en continue geïdentificeerd worden en actie moet worden ondernomen om de kans op risico’s te verkleinen of de kwaliteitsimpact te matigen.

Bij agile moeten gebruikerservaringen die een groot risico vormen zo vroeg mogelijk in project gedaan worden. Het is beter om vroeg met het risico om te gaan, omdat er dan nog ruimte voor is. Spikes zijn een goede manier om vroeg mogelijk met risico’s in projecten om te gaan. Ze verminderen projectverstoringen en helpen het agile team en producteigenaren om snel feedback te krijgen over productmogelijkheden. Om het risico te verminderen en kwaliteit te vergroten, zouden agile teams hun vermogen moeten ontwikkelen om hoge kwaliteit code af te leveren.

Planningsdruk

Er zijn verscheidene goede boeken geschreven over het managen van tijd en mensen in projecten, zoals The Mythical Man van Fred Brooks en Peopleware van Tom DeMarco en Tim Lister. Ze maken duidelijk dat (project- en lijn)managers voorzichtig moeten zijn in hun teammanagement en moeten voorkomen dat professionals overladen worden met werk.

Mijn ervaring is dat het stabiel houden van teamcompositie teamleden in staat stelt om continue te leren en te verbeteren. Ook XP promoot een kerntoepassing van de “40-urige werkweek”, die ernaar streeft om druk op teamleden te verminderen en zo te voorkomen dat ze fouten maken die resulteren in een mindere kwaliteit.

Waarom zetten projectmanagers tijdsdruk op hun teams? Ik weet het niet en het verbaast me nog steeds, dus ik kan alleen maar gissen naar hun redenen om dat te doen. Misschien omdat ze denken dat druk zetten op mensen ze productiever maakt? Het team deadlines nodig heeft om resultaten te boeken? Ze kunnen het zien als onderhandeling, waar ze de optimale hoeveelheid werk willen vinden dat afgeleverd kan worden binnen een bepaald tijdframe? Als u weet wat de projectmanagers beweegt om druk op hun teams te zetten, laat het me alstublieft weten in een reactie op deze post!

Opgesomd zijn er een hoop goede redenen voor projectmanagers om planningsdruk te verminderen, om zo de kwaliteitsrisico’s te verminderen. Waarom het nog steeds gedaan wordt, verbaast me nog (te) vaak.

Conclusies

Projectmanagement kan kwaliteit stimuleren. Door het maken van beslissingen die het project team in staat stelt om software te ontwikkelen, en door het oprichten van een structuur en omgeving waarin het team op een efficiënte manier kwaliteitsproducten af kan leveren. En door het tijdig nemen en communiceren van besluiten zodat professionals weten wat er besloten is met aandeelhouders. Samen met het Senior Management, Operationeel Management en het procesmanagement, zal projectmanagement de professionals stimuleren hogere kwaliteit producten af te leveren, op tijd en binnen budget, die aan hun kwaliteitsdoelen voldoet.