{"id":6729,"date":"2014-08-22T11:45:13","date_gmt":"2014-08-22T11:45:13","guid":{"rendered":"https:\/\/www.bridge-global.com\/blog\/blog\/\/?p=6729"},"modified":"2021-12-07T08:55:08","modified_gmt":"2021-12-07T08:55:08","slug":"how-project-management-drives-software-quality","status":"publish","type":"post","link":"https:\/\/www.bridge-global.com\/blog\/how-project-management-drives-software-quality\/","title":{"rendered":"How Project Management drives Software Quality"},"content":{"rendered":"

<\/p>\n

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<\/a>\u00a0work 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?<\/p>\n

The series on \u201cWhat Drives Quality<\/a>\u201d describes both technical activities and supporting quality activities. Previous articles explored what\u00a0Senior Management<\/a>\u00a0and\u00a0Operational Management<\/a>\u00a0do to ensure that quality software products are delivered to customers. This article describes how Project Management drives\u00a0quality<\/a>.<\/p>\n

\u00a0<\/strong>Understanding what drives quality enables you to take action before problems actually occur, saving time and money.<\/strong><\/p>\n

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

\u00a0<\/strong>Managing Projects<\/strong><\/p>\n

With project management I mean managing of projects and programs that include software development and delivery. This can be waterfall projects, RUP, or\u00a0Agile project Management<\/a>; the basic principles of project management and their contribution towards software quality is needed for all these kinds of projects.<\/p>\n

Project managers can use specific project management methods or certifications (eg.\u00a0PRINCE2<\/a>,\u00a0PMI<\/a>\u00a0or\u00a0IPMA<\/a>), these methods describe the quality activities that should be performed. Also the\u00a0CMMI includes process areas that cover project management<\/a>\u00a0and the quality activities that are typically performed in projects.<\/p>\n

Factors that drive Quality by Project Management are:<\/p>\n

    \n
  1. Decision Making Capability \u2013 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.<\/li>\n
  2. Project Portfolio Management \u2013 Planning and tracking of the set of projects, including project steering groups and all decisions made to start, continue, cancel, and conclude the project.<\/li>\n
  3. Project Management Capability \u2013 Skill and experience level of project managers.<\/li>\n
  4. Risk Management Process Capability \u2013 Awareness of project risks, the maturity of the process, and the capability of managing risks.<\/li>\n
  5. Planning Capability \u2013 The ability to estimate, plan, and track projects with respect to the quality of the delivered product.<\/li>\n
  6. Scope Stability \u2013 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.<\/li>\n
  7. Schedule Pressure \u2013 The way deadlines are used to put pressure on projects and people to deliver on time.<\/li>\n
  8. Operational Overview and Insight \u2013 Insight into the status of ongoing projects (e.g., processes used, documents delivered, quality of the documents).<\/li>\n
  9. Operational Line Management \u2013 Activities done by department managers in their role as responsible for the short term activities.<\/li>\n
  10. Project Management Process Adherence \u2013 Checks (e.g., audits or assessments) to determine whether the baselined processes are being followed and if they are effective and efficient.<\/li>\n<\/ol>\n

    Decision Making Capability<\/strong><\/p>\n

    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\u00a0how the project is steered and monitored<\/a>, 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.<\/p>\n

    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\u00a0product quality that is required<\/a>, since this can have much impact on the work that needs to be done. Aspects of quality are the\u00a0knowledge and skills that are needed<\/a>to develop the software, the quality activities that need to be done (eg.\u00a0pair programming<\/a>,\u00a0reviews<\/a>\u00a0ortesting<\/a>) and the\u00a0process that will be used<\/a>\u00a0to do the work. Decisions can either be documented on the scrum board, or in the Definition of Done (DoD). Retrospectives<\/a>\u00a0can 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.<\/p>\n

    Do we still need projectmanagers to\u00a0manage projects with agile teams<\/a>? Yes, but their role will be different. Project managers can for instance organize the co\u00f6rdination 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.<\/p>\n

    In the end, a project manager is also responsible for\u00a0steering product quality in agile teams<\/a>, and for the\u00a0reporting of his\/her agile project<\/a>. 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.<\/p>\n

    Risk Management<\/strong><\/p>\n

    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.<\/p>\n

    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.\u00a0Spikes 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<\/a>.<\/p>\n

    Schedule Pressure<\/strong><\/p>\n

    Several good books have been written on managing time and people on projects, like\u00a0The Mythical Man Month from Fred Brooks<\/a>\u00a0and\u00a0Peopleware from Tom DeMarco and Tim Lister<\/a>. They make it very clear that (project and line) managers should carefully manage teams, and prevent that professionals are overloaded with work.<\/p>\n

    My experience is that\u00a0keeping teams composition stable<\/a>\u00a0enables team members to learn and improve continuously. Also XP promotes a Core Practice \u201c40 hour workweek\u201d, which aims to reduce pressure on team members to prevent them from making mistakes that result in less quality.<\/p>\n

    Why do project managers put time pressure on their teams? I don\u2019t 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!<\/p>\n

    Summing up, there are lot\u2019s 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.<\/p>\n

    Conclusions<\/strong><\/p>\n

    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\u00a0Senior Management<\/a>,\u00a0Operational Management\u00a0<\/a>and Process Management, Project Management drives professionals to deliver high quality products, on time and within budget, which meet their quality goals.<\/p>\n

    \"\"<\/a><\/p>\n

    <\/p>\n

    \"\"<\/a>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<\/a>. 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?<\/p>\n

    De serie \u201cWhat drives Quality<\/a>\u201d beschrijft zowel de technische activiteiten, als de ondersteunende kwaliteitsactiviteiten. Eerdere artikelen bekeken wat Senior Management<\/a> en Operational Management<\/a> doen om te zorgen dat kwaliteitssoftwareproducten worden geleverd aan klanten. Dit artikel beschrijft hoe Projectmanagement kwaliteit<\/a> stimuleert.<\/p>\n

    Begrijpen wat kwaliteit stimuleert geeft je de mogelijkheid actie te ondernemen wanneer problemen daadwerkelijk optreden, wat geld en tijd bespaart. <\/strong><\/p>\n

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

    Projecten Managen<\/strong><\/p>\n

    Met projectmanagement bedoel ik het managen van projecten en programma\u2019s die softwareontwikkeling en -aflevering omvatten. Dit kunnen watervalmethodes, RUP, of Agile projectmanagement<\/a> zijn; de basisprincipes van projectmanagement en hun toevoeging aan softwarekwaliteit zijn nodig in al deze projectvormen.<\/p>\n

    Projectmanagers kunnen specifieke projectmanagementmethodes of \u2013certificeringen (bijv. PRINCE2<\/a>, PMI<\/a> of IPMA<\/a>) gebruiken. Deze methodes beschrijven de kwaliteitsactiviteiten die uitgevoerd zouden moeten worden. Ook de CMMI bevat procesgebieden die projectmanagement<\/a> dekken en de kwaliteitsactiviteiten die vooral in projecten uitgevoerd worden.<\/p>\n

    Factoren die kwaliteit stimuleren door projectmanagement zijn:<\/p>\n

      \n
    1. Besluitvormend vermogen \u2013 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.<\/li>\n
    2. Projectportfoliobeheer \u2013 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.<\/li>\n
    3. Projectmanagementvermogen \u2013 Vaardigheid en ervaringsniveau van projectmanagers.<\/li>\n
    4. Risicomanagementvermogen \u2013 Bewust zijn van projectrisico\u2019s, de ontwikkeling van het proces en het vermogen om risico\u2019s te managen.<\/li>\n
    5. Plannend vermogen \u2013 Het vermogen om te schatten, plannen en nalopen van projecten met het oog op de kwaliteit van het af te leveren product.<\/li>\n
    6. Scopestabiliteit \u2013 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.<\/li>\n
    7. Planningsdruk \u2013 De manier waarop deadlines gebruikt worden om druk zet op de projecten en op de mensen voor het op tijd afleveren hiervan.<\/li>\n
    8. Operationeel overzicht en inzicht \u2013 Inzicht in de status van lopende projecten (bijv. processen die gebruikt worden, afgeleverde documenten, kwaliteit van die documenten).<\/li>\n
    9. Operationele lijnbeheer \u2013 Activiteiten die gedaan worden door afdelingshoofden in hun rol als verantwoordelijke voor activiteiten op korte termijn.<\/li>\n<\/ol>\n

      10. Projectmanagement adherente processen \u2013 Controles (bijv. audits of assessments) om vast te stellen of de basisprocessen gevolg worden en of ze effectief en effici\u00ebnt zijn.<\/p>\n

      Besluitvormend vermogen <\/strong><\/p>\n

      Van projectmanagers wordt verwacht dat ze beslissingen maken die benodigd zijn om het project te laten afleveren en z\u2019n 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<\/a>, kunnen er grote verschillen zijn in welke besluiten genomen worden door de projectmanager en welke door leden van het projectteam of door aandeelhouders.<\/p>\n

      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<\/a>, aangezien dit veel impact kan hebben op het werk dat gedaan moet worden. Aspecten van kwaliteit zijn de kennis en vaardigheden die benodigd zijn<\/a> om de software te ontwikkelen, de kwaliteitsactiviteiten die gedaan moeten worden (bijv. pair programmeren<\/a>, reviews<\/a> of testen<\/a>) en de processen die gebruikt worden<\/a> om het werk te doen.<\/p>\n

      Besluiten kunnen gedocumenteerd worden op het scrumbord, of in de Definition of Done (DoD). Terugkoppelingen<\/a> 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.<\/p>\n

      Hebben we nog projectmanagers nodig om agile teams te leiden<\/a>? 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\u00efntegreerd en\u00a0 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.<\/p>\n

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

      Risicomanagement<\/strong><\/p>\n

      De kwaliteit van de softwareproducten is gerelateerd aan de manier waarop risico\u2019s beheerd worden in projecten. Productkwaliteitsrisico\u2019s moeten vroeg en continue ge\u00efdentificeerd worden en actie moet worden ondernomen om de kans op risico\u2019s te verkleinen of de kwaliteitsimpact te matigen.<\/p>\n

      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\u2019s 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.<\/a><\/p>\n

      Planningsdruk<\/strong><\/p>\n

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

      Mijn ervaring is dat het stabiel houden van teamcompositie<\/a> teamleden in staat stelt om continue te leren en te verbeteren. Ook XP promoot een kerntoepassing van de \u201c40-urige werkweek\u201d, die ernaar streeft om druk op teamleden te verminderen en zo te voorkomen dat ze fouten maken die resulteren in een mindere kwaliteit.<\/p>\n

      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!<\/p>\n

      Opgesomd zijn er een hoop goede redenen voor projectmanagers om planningsdruk te verminderen, om zo de kwaliteitsrisico\u2019s te verminderen. Waarom het nog steeds gedaan wordt, verbaast me nog (te) vaak.<\/p>\n

      Conclusies<\/strong><\/p>\n

      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\u00ebnte 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<\/a>, Operationeel Management<\/a> en het procesmanagement, zal projectmanagement de professionals stimuleren hogere kwaliteit producten af te leveren, op tijd en binnen budget, die aan hun kwaliteitsdoelen voldoet.<\/p>\n

      <\/p>\n

      <\/p>\n

      <\/p>\n","protected":false},"excerpt":{"rendered":"

      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?<\/p>\n

      The series on \u201cWhat Drives Quality\u201d 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.<\/p>\n","protected":false},"author":54,"featured_media":45409,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14],"tags":[],"class_list":["post-6729","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-offshoring"],"featured_image_src":"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2014\/08\/Mangement.jpg","author_info":{"display_name":"Ben Linders","author_link":"https:\/\/www.bridge-global.com\/blog\/author\/ben-linders\/"},"_links":{"self":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/6729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/users\/54"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/comments?post=6729"}],"version-history":[{"count":4,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/6729\/revisions"}],"predecessor-version":[{"id":49351,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/6729\/revisions\/49351"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media\/45409"}],"wp:attachment":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media?parent=6729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/categories?post=6729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/tags?post=6729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}