Using DSDM to Augment the PMBOK
Mike Griffiths: Quadrus, Per Magnus Skoogh: Precipio , Steve Messenger: Napp
Introduction
IT Project success or failure is often defined by how well key aspects of a project are handled. The effectiveness of communications between stakeholder groups, the rate of project progress, how evolving requirements are addressed and keeping up with changing technology are often indicators of whether a project will ultimately succeed or fail. By applying proven and practical project management techniques to address these telling project factors the probability of succeeding can be influenced.
DSDM is an agile approach to project management; it is not just a philosophy but a complete and mature framework for developing IT solutions. When employed as an augmenter to the PMBOK, DSDM techniques can greatly enhance the PMI Project Manager’s toolbox whilst still providing and maintaining the controls required to affect successful project outcomes. The Project Management Institute (PMI) is a North American based project management organisation with over 230,000 members worldwide. Through its handbook “Project Management Body of Knowledge” (PMBOK) and associated publications, the PMI provides project management guidance for a wide variety of industries. While the PMBOK is a collection of project management best practices and DSDM is a development framework, there are many synergies and alignment points.
If you or your projects have ever been affected by any of the following you may want to read on:
Managing Communication
Communication failures are a leading contributor to project failures. In fact, project management author Francis Hartman observes from a study of many failed projects, that some form of communication failure is, more often than not, behind all project failures.
Software projects can often seem to enter a black hole, where, following an initial liaison with the stakeholders, the developers go away for weeks or months at a time before returning with something that barely meets requirements. This makes the Project Manager's life extremely difficult, providing little in the way of concrete milestones against which progress can really be measured and demonstrated to project stakeholders.
Clearly, avoiding communication failures is a high priority for project managers. The IT framework, DSDM, provides several built-in techniques to promote inter-team and stakeholder communication including:
Facilitated Workshops – Discussing requirements in the presence of other project stakeholders increases the whole group’s awareness around the project and promotes communications. As questions emerge and are answered, people become aware of differing areas of expertise amongst stakeholders and new communication channels are formed. This does not occur when requirements are elicited one-on-one via interviews or in small meetings.
Daily Meetings – The daily meeting where team members describe the items that they have been working on, planned work and any obstacles they may have encountered is an excellent inter-team communication forum. Team members learn what other people are working on which helps prevent duplicated efforts. By raising potential issues early, information exchange is encouraged as team members can then help one another resolve problems.
Prototype Review Sessions – A major communications enhancer are the sessions to review progress and functionality - with the Ambassador users regularly throughout the timebox, and with the key representatives at the end of every timebox. Evaluating implemented features bridges the gulf of evaluation that can form between user descriptions and developer interpretations. By regularly meeting to review and discuss the evolving prototype, stakeholder expectations are reiterated, development team understanding is validated and true project progress is communicated. These regular reviews of features with the business/user representatives mitigate a large proportion of project miscommunications. Issues are uncovered early, while there is still time to fix them, new and evolving requirements are identified by the business and opportunities for misunderstanding are minimised through functionality demonstrations.
Frequent delivery of products – Early and frequent demonstration of product features that can be test driven by the users gives more visibility to the project. This also ensures timely feedback which is beneficial in enabling all stakeholders to remain engaged in the project. The end users can see the solution develop before them and have real power to change its course to meet real business requirements, which may actually change during the development lifecycle. As a result, senior stakeholders and the PMI project manager have a tangible and real gauge by which to measure the project’s progress and a strong sense of how the project is tracking.
Embracing Changing Requirements
IT solutions are created to support business needs and these business needs change and adapt as the business responds to new competition, legislation and technology capabilities. This means that even during the creation of a solution it is normal for the requirements to evolve to adapt to changing business needs. As business becomes more globalised this rate of change is accelerating as market reach extends beyond geographic regions and competitors can be located half way around the world. It is a reality that IT projects are experiencing increasing rates of changes on projects with no apparent sign of a slow down – it would be foolish to think that business requirements would stop just because an IT project has been initiated to address a need in that business area; it is exactly these changes that often precipitate the need for IT projects to be initiated.
Another characteristic of software is that it is intangible and difficult to describe. The same solution is rarely built twice and so comparisons to previous solutions are of little help when describing or documenting requirements. Given these difficulties it is not surprising to find that more often than not the software requirements captured initially often differ from the true business requirements. One approach traditionally followed to address this problem is to define the upfront requirements in more and more detail, in an attempt to flush out a complete, unambiguous understanding of functionality. This approach, though comforting in some respects can very quickly mean that requirements become incomplete or inaccurate as business needs change and change quickly. An alternative approach is to prototype something, put it in front of the users early and ask if it meets their needs. Working from this baseline prototype, features and functionality can evolve towards the true business requirements. While this approach appears counter intuitive to some people who are looking for more rigorous approaches, it leverages a well known characteristic of user requirements: evaluation is best done against working software. Users can better articulate their true requirements when they have access to a partial implementation. The acronym “IKIWISI” which translates to “I’ll know it when I see it”, describes this phenomenon and points to incremental development being a more effective approach towards requirements comprehension than upfront, perceived to be thorough, document heavy specification.
The fact that requirements change as businesses evolve and that software is very difficult to articulate creates a project environment where changing requirements are more the norm than the exception. DSDM recognises this reality and embraces the concept of ongoing change through its techniques for requirements prioritization and iterative planning. Planning should not only be done at the start of a project but also undertaken on an ongoing basis, recognising that changing requirements are a fact of life on many IT projects; in accepting and adapting to this reality, the project manager and team are in a position to work with the pulls on a project as opposed to trying to brace for the impact of impending change.
Managing Architecture
The rate at which today’s world of technology is evolving makes it difficult to select appropriate hardware and software tools for any given project’s needs. With that in mind, it becomes even more challenging to set all the components of the final production software and hardware infrastructure at the start of a project. DSDM offers techniques to evaluate different architectural components and to be able to evolve these based on a changing set of available solutions. By structuring short timeboxed efforts which enable validation of prioritised architectural options, architectural risk can be addressed early on while the benefit of validating architectural approaches and allowing for evolutionary adjustments can be achieved.
Some may see this approach as a lack of architectural control, whereas in fact, DSDM addresses this concern through the creation of a required deliverable, called the Systems Architecture Definition, during the early Business Study phase of the project. This sets out the blueprint for the architecture, taking into account the organisation’s existing infrastructure policies and involving the technical experts in this area.
Complementary Methods
DSDM is an example of an agile method which is complementary to the practices defined in the PMBOK. The DSDM Consortium is a body of project management professionals who have come together world-wide to create a project management framework in response to the needs of evolving project management challenges as faced by practicing project management professionals. Independent of any vendor influence and developed by PMI knowledgeable members, it is natural that the DSDM framework shares many of PMI’s core values. To more effectively address the needs of the project management discipline, DSDM is light in some areas where the PMBOK provides best practice guidance, for example sponsor management. The PMBOK is deliberately industry agnostic, providing project management best practice that is applicable across many industries. DSDM can be used alongside the PMBOK to provide IT development best practices for the IT application area.
Figure x below shows how the PMBOK provides Guidelines and Best Practice information within the project lifecycle (x axis) and various project roles (y axis).
Figure X – PMI Scope Coverage
In figure x it can be seen that the PMBOK guide provides coverage from the early Setup phase of a project through to Deployment and Training. It provides Project Management and Sponsor roles guidelines, but does not specifically address user management or development team role guidelines.
Figure Y – PMBOK and DSDM Coverage
When the PMBOK is used in conjunction with DSDM, several additional areas are augmented as shown in figure y.
DSDM complements the PMBOK by providing early lifecycle coverage of pre-project activities such as feasibility analysis and provides role guidelines for user and development teams. In addition to these role guidelines, it also provides templates for common project deliverables. In this way DSDM provides a set of IT project specific tools to help strengthen the PMBOK framework.
What Should Agile IT for PMBOK contain?
The best help DSDM can give the PMI Project Manager running an IT project is to ensure he is aware of and uses key principles and best practices from the IT application area. Several of these principles and best practices are integrated into DSDM. By blending philosophy and best practices into a complete and mature framework for developing IT solutions project managers have tangible and proven resources and techniques to affect progress and success in IT delivery. The techniques DSDM and other agile approaches offer can greatly enhance the PMI Project Manager’s toolbox whilst still providing and maintaining the controls required. The key aspects of the DSDM framework are detailed below.
Managing Time, Cost and Scope
The Project Manager’s Dilemma
It is a well known fact that it is impossible to fix time, cost and scope on a project and still achieve the required level of quality for a solution. Time and cost are always important but often these two overrun in order to meet all the scope requirements that were specified in requirements gathering discussions held at the start of the project. It is also true that requirements each have a varying degree of business value and that more than likely some requirements will provide little to no business benefit. It is the business value variable associated with a requirement that can be leveraged to resolve the dilemma; by prioritising requirements based on business value scope can be flexed, thereby leaving time and cost as the fixed dimensions.
This can ease the Project Manager’s job in needing to control and recalibrate resource and budget. It also acknowledges the fact that most customers want business benefit on time and on budget, and in exchange are willing to consider foregoing other features.
By challenging the belief that projects should deliver all of the scope and add people or time when required to accommodate this outcome, the paradigm is turned upside down – time, and if so desired, cost is fixed while scope is the malleable element; critical business requirements are delivered first and the time and resources are aligned to meet this objective. In doing so, stakeholders can tangibly see true business value delivered on time and on budget.
How can we flex scope?
Software development follows Pareto’s rule in that 80 % of the benefit is derived from a rather small part of the functionality or deliverables. This is why prioritisation is the key to success in any project; this is particularly true when there are vague and unclear requirements. In practice, at least 50% or more of the requirements actually deliver little or no business benefit. If these nominal business value requirements can be identified and prioritised as low business value items, then dropping them out will not be as difficult as one might assume. It should also be noted that the amount of work effort associated with any given requirement does not correlate to its direct business value; in those cases where high work effort is required to deliver little business value; the decision can be more readily made to forego its implementation
There are additional benefits to adhering to stated project timelines. The mindset that moving deadlines to accommodate desired project outcomes is a dangerous paradigm to adopt in projects and for the organization. If we couple this with the reality that projects are often interdependent, it is apparent that a domino effect can easily occur where the delays in one project can carry over and magnify when examined in context to interdependent projects. A one week late project can in turn cause a delay in several other projects. This then has implications on staffing requirements, which may further introduce additional delays. Every week that a five-person project is late can thus translate into hundreds of thousands of dollars. Constant re-scheduling of activities in projects is very costly and can create disruption for other parts of the organization whilst potentially adding further cost increases. When assessed in the greater scope of business impact, de-scoping is often many times much less costly than the alternative of increasing time and/or incurring greater cost. It is true that he who is first to market with new functionality is often the one to profit most greatly but this can also be refined to “he who is first to market with critical new features that maximize business value while being on time and on budget stands to profit even greater”.
Managing scope and requirements through prioritisation can be extremely effective if done consistently and diligently. If the paradigm of prioritisation is to be effective in practice, it needs to be adopted at the core of the project and the project’s culture. There are explicit techniques outlined in DSDM that help to manage flexing scope successfully – for instance, timeboxing, prototyping and MoSCoW prioritisation. These three techniques work together to make flexing scope a realistic and working option. This white paper shows how these techniques work together to bring about a project which has a higher probability of delivering on time while flexing scope. These specific techniques map closely to the PMBOK Scope Management, Change Management and Time Management knowledge areas.
Prototyping
Prototyping is a valuable tool in the project manager’s kit and is a technique that supports the project in more ways than one.
MoSCoW and the prioritised work breakdown structure (WBS)
Focus on deliverables -
PMI recommends the practice of using a product based WBS; this approach also fits well with DSDM’s prioritisation philosophy. The leaf nodes of the WBS tree structures become the deliverables that can be prototyped, inspected, tested and signed off; the key is that the work defined at this level would result in a tangible, demonstrable unit of work. Similarly, this paradigm would also work with a product breakdown structure (PBS). The goal is to keep the WBS to a maximum of three levels per a 3-8 person team and to not identify micro-deliverables.
The Prioritised List of Deliverables and MoSCoW rules
The leaf nodes in the WBS structure are organised into the prioritised requirements list which in a PMI/DSDM project translates to a list of deliverables. This list is commonly known as the MoSCoW list.
Since we are adjusting scope to ensure delivery on time and on cost, prioritisation becomes the primary tactic for managing the various components of the project. Prioritisation needs to be deeply ingrained in every aspect of the project; on an ongoing basis requirements, deliverables, test cases, stakeholders, sites and user groups etc., need to be prioritised, regularly revisited and re-prioritised. By extending the MoSCoW list to include these elements the overall prioritisation effort can be managed as a holistic view.
MoSCoW is simply a pragmatic means of prioritising project components that has proven very effective in real projects. It should be duly noted that the use of MoSCoW is, however, not an excuse to avoid doing proper estimation. One of the main benefits of MoSCoW in a project is that it allows the opportunity for a discussion around true business value and the tradeoffs of possibly not undertaking certain requirements or activities while allowing the project to maintain timeline and cost.
Stakeholder Management
Team Development - A core DSDM belief is that the right team, empowered to make decisions at the appropriate level, can deliver real business benefits in a short timeframe. The key is to ensure all stakeholders are adequately represented and to leave the decisions to those who should make them. So, for instance, representatives from the customer and the performing organisation for whom the solution is being developed are a core part of the project team and will make all decisions concerning requirements, usability etc. It would also be a natural choice that this team would also be responsible for the testing and documentation of the solution. This gives them a sense of ownership of the solution and that is the key to success – by being active participants in its creation they do not feel that they have had a solution thrust upon them once it has been completed. It also requires them to have accepted the constraints and timescales of the project and to work as a team towards achieving the key business benefits.
When roles on projects are not clearly defined this can lead to duplication of effort or, worse, deliverables being missed because everyone thought it was someone else’s job. DSDM clearly defines various roles that may be relevant on a project and addresses this potential confusion so that a high performing close-knit team with a collective responsibility can be designed and put in place as part of the early setup of the project.
Project Human Resource Management
Clear roles and a clear separation of duties are vital for any successful project. In a successful IT project this means we must clearly separate who defines the requirements and who delivers them. The customers and users are responsible for defining the requirements and their associated prioritisation based on business benefit. The project manager, on the other hand, is responsible for delivering the implemented requirements and possibly facilitating requirements prioritisation exercises; he or she would have limited involvement in the actual creation and prioritisation of requirements.
The customer and user representation can be a full time or part time role. The time commitment must be "enough" - whatever "enough" is for that particular project. For client-vendor and in-house projects this can mean a real user taken from the business to work more or less full time on the project. Equivalently, product development organisations must find a suitable mix of “user proxies”, which usually includes a product manager acting as “user proxy co-coordinator”. This separation of duties along with a strong and competent project manager in combination with equally strong, competent and available user/customer is what is necessary to effectively define and prioritise requirements.
DSDM also addresses project steerage and management as defined in PMBOK by defining roles for Project Manager, Project Board and Steering Committee.
Time management
Timeboxing - Managing time is critical to the success of any project. The concept of timeboxing is a best practice technique that helps with this. Timeboxing is a process by which defined objectives are reached at a pre-determined and immovable date through continuous prioritization and flexing of requirements using prototyping and the MoSCoW rules. At the end of the timeboxed period, the team will produce something visible in order for progress and quality to be assessed. Examples of what a timebox could deliver include prototypes and documents that describe the solution, a partial solution component or an early version of the solution. All necessary reviews and tests are contained within the given timebox so as to accommodate any necessary rework or change into subsequent timeboxes. Through timeboxing project teams are less apt to lose their focus and subsequently less likely to run out of control.
Just as in the PMBOK, the team working in a timeboxed paradigm is empowered. The team working in the timebox must agree on the objectives, and the developers and testers must themselves estimate the time required. At the deadline, the users must be able to approve the delivery of the products covered by the timebox. If it appears that deadlines could be missed, the deliverable should be de-scoped, dropping the lower priority items, i.e. Should Have and Could Have requirements can slip while the timeline stands unchanged. Continuous negotiation of what is important is at the team level, and is worked at together and agreed upon prior to moving forward.
DSDM Timeboxes
The timebox is the mechanism for handling flexibility of requirements in DSDM. In any project there is a fixed completion date which provides an overall timebox for the work to be carried out. DSDM refines the concept of timeboxing by nesting shorter timeboxes of two to six weeks within the overall time frame.
Each timebox will typically pass through three phases.
Each timebox has an immovable end date and a prioritized set of associated requirements. Some of these are mandatory while others are of a lesser priority. The mix of both is essential to have because if all the requirements are mandatory, there would be no room for manoeuvre when things don't go perfectly to plan or when new requirements surface. The prioritization of the requirements throughout the timebox are checked and possibly reassigned using the MoSCoW rules.
Planning
Incremental Development
Frequent Delivery -Vague, unclear and difficult to define requirements represent a risk in a project and are all too often characteristic of many projects. To mitigate this risk DSDM looks to early integration and early sign-off and acceptance by the users and customers.
Early integration and early sign-off can be achieved at various levels, namely,
At the project level, DSDM looks to deliver benefit to the customer by delivering something usable as often as possible. As a guide, a major deliverable should be produced no more than three months between each deliverable. This is not always possible if there are major technology or architectural issues that need to be addressed. Where possible, delivery increments of one month work effectively and can be achieved in situations where architecture is in place and technology is well established.
At the timebox iteration level, a tangible delivery should be targeted for every 2-6 weeks. At the completion of a timeboxed iteration the expectation is that some portion of the overall solution requirements is produced; what is included is fully coded, analyzed, integrated, tested, documented and signed off. This approach allows the customer to see tangible evidence of progress early on in the project. Though the functionality demonstrated may not be production release quality, the opportunity to see a portion of the solution up and running serves well to prove (or disprove) whether development efforts are heading in the right direction.
This means that while a project with crystal clear requirements will focus on processes over time as below
and focus on different types of work like below:
… a typical IT project with unclear requirements will focus on processes over time as below
and put a concurrent focus on different work types as below:
Every timeboxed iteration is hence, in fact, a mini-project where we ensure we have wrapped up part of the solution (expected result) including coding, testing, integration, etc.
All of this is about reducing risk. Through incremental delivery we are, from a project risk point of view, able very early to:
From a business point of view we can
The daily stand-up meeting ensures that we eliminate risk and verify progress on a daily level. If every timeboxed iteration is a mini-project, we can call every day a micro-project.
Quality Management and Control
No Compromise on Quality or Control -
Although DSDM is a paradigm shift from PMBOK, both schools of thought agree that scope can be varied. By varying scope it does not mean that the quality of the delivered solution is jeopardised. DSDM has built-in methods for ensuring that the delivered solution will be fit for purpose and will meet the quality criteria, defined up front and with each deliverable within the project. The methods to achieve this include traditional techniques such as integrated testing, reviews, and constant feedback but also bring some newer techniques such as facilitated workshops to ensure understanding and agreement of requirements, prototyping to bring to light the misunderstandings and the right people charged with making the right decisions.
The control techniques that timeboxing brings can be seen as far more powerful than traditional controls. A timebox's primary purpose is to produce a set of quality-assured deliverables, which can be seen and demonstrated. It is therefore easy to see whether or not the project is on course. Since at the lowest level, timeboxes are short, potential issues in delivery can be picked up quickly and the project can be put back on track immediately.
Think about it first!
DSDM doesn't just jump in; it is careful to assess whether the project is viable prior to proceeding any further. The first two phases in DSDM are called the Feasibility and Business Study phases. In these, one is defining the scope of the problem at a high level, looking at the system architecture, checking to see if following a DSDM approach is appropriate and planning out the development phases. This means one has a firm foundation to move forward and is not making key decisions on the fly. So one may have decided one wants a new car, it has to have four wheels and be drivable on the fast roads and in traffic, but the trim, size of engine, controls etc. are still up for debate!
Risk Management
The PMBOK contains a complete risk management method. Contained in the PMBOK is a formal process to manage risk, several good-to-know terms and a list of techniques that might be useful such as decision tree analysis and Monte Carlo simulation. DSDM is less formal, but nevertheless contains quite a few techniques and principles that greatly reduce the risks for a given project. Some of these key techniques and principles are:
Conclusion
In summary, PMBOK working together with DSDM provides a very strong approach to delivering IT solutions. It recognizes that the needs and requirements of users change through a project and ensures those needs are met by consolidating all stakeholders into one team.
Unlike other agile approaches, DSDM as an augment to PMI PMBOK provides control of the time, quality, cost and resource components through techniques such as timeboxing, prototyping, facilitated workshops, reviews and integrated testing. It aids effective delivery by fixing the time and resource dimensions and putting priority on those requirements that will deliver real and critical business benefit. Together, PMI and DSDM becomes an invaluable weapon in the fight against poor IT projects producing bad solutions.
Agile software development techniques often seem to conflict with project management best practices. However, DSDM offers a framework for agile software development that is compatible with the PMBOK guidelines. By using DSDM techniques within a framework of PMBOK best practices the benefits for each approach can be maximised.