How to mash-up and benefit from PM and the Design Thinking Process

The Homer a mash-up car made for one user – Homer

Ever struggled with managing your projects or PMs trying to do so? Well, there is an app… hmm… or something different for that.

Recently I took on the Design Council’s Double Diamond process, “revamped” it, and published it (Link at the end of the post). People have questioned how my approach would relate to “real” project management and projects.

This follow-up post is about my mash-up approach to answering this. This is not about comparing the HCD process to PM but to overlay the two disciplines in order to gain an understanding when working in an environment where people rely one or the other.

Mashing-up stuff doesn’t always work... But f*ck it. I’m doin it anyway.

If you are familiar with my Revamped Double Diamond Design process skip the next paragraph.


Revamped Double Diamond

The Revamped Double Diamond is a design process framework based on the Design Council’s (2007) Double Diamond.

Latest and slightly updated version of my Revamped Double Diamond (01.09.2016). “Themas and clusters” are now a before “Insights”

It aims at making sense of the design process and providing guidance and clarity in order to tackle a design challenge. The framework incorporates tools, methods and techniques from various sources to do so (find links to my detailled article at the end of this post).


Project Management in a nutshell

“Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements” (PMI, 2013).

I’m not going deeper into PM theory and focus on two major PM “families” : “Waterfall” (traditional, sequential) and “agile”.

One… wait… two more things, though:

When talking about “Agile” I am mainly referring to the mindset and way of thinking rather than one specific method, based on the “Manifesto for agile software development” (Beedle et al., 2001).

The manifesto lists four core values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Royce (1970) visualised the probably first and later referred to as “waterfall” PM method, incorporating a two-sided relationship between development phases. He linked each phase back to its predecessor acknowledging potential iterations.

“Waterfall” has often been falsely visualised in a “one-way only” manner. Thus, it has been accused of being strictly linear, making it impossible or at least difficult to move back, once a step has been made.

When relating to “waterfall” in my context I refer to the iterative notion introduced by Royce.

Screenshot from Royce, D.W.W. (1970) ‘MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS’

Project Management and the Revamped Double Diamond

Although visually implying, the “Revamped Double Diamond” shouldn’t be perceived as one-way process and account for an agile and iterative behaviour.

There are different approaches to tackling design challenges, the related process and PM.

They depend on the type of organisation that is taking upon them, their focus and role within the challenge, restrictions and boundaries given by the project scope and a desired outcome of a project.

Depending on these variables the process and focus on phases may vary (Sam Dunne, 2016).

Different types of project goals and the resulting focus in the design process. Source: Sam Dunne

Merging PM approaches and the Revamped Double Diamond

How might we apply PM approaches to the Design process?

Two visual approaches:

The Revamped Double Diamond overlaid with a “build-measure-learn” loop based on Rise (2011) and Gothelf (2013)

The Revamped Double Diamond overlaid with a Scrum approach based on Jongerius and Berghuis (2013) and Schwaber and Sutherland (2013)

Discover and Define meet Sprint 0, Assumptions and Hypotheses

The core notion of the approach overlaying “Discover and Define” with “Sprint 0, Assumptions and Hypotheses” is thorough research as foundation of a project.

The goal is to ensure “the right problem to solve” or “the question to ask” is addressed.

Contrary, quickly building assumptions of user behaviours based on the initial brief may be another approach to starting a project.

Jeff Gothelf (2013) points out that Lean UX projects start with assumptions summarised in a problem statement. Assumptions go into a prioritisation process, in which they are placed on a two-axis matrix.

Certainty vs Proximity Matrix

The point of prioritising assumption is to come up with formulating a hypothesis statement that looks at potential solutions that are the foundation for generating ideas that might be tested later.

The hypothesis statement sets a clear vision for the work.

The activity of formulating and prioritising assumptions may be related to the Revamped Double Diamond stage of “Defining and Synthesising” whereas phrasing hypotheses and ideate may be considered as a form of “Design / Ideation”.

Relating to a scrum methodology the first diamond plus the “Design / Ideation” subphase can also be considered “sprint 0”.

Unlike “waterfall projects”, scrum projects are made of so-called sprints, which are portions of a project that usually last for a defined number of weeks in which a multidisciplinary team works together on a challenge (“Get Agile”, Pieter Jongerius and Gert Hans Berghuis, 2013).

Although scrum is a progress driven PM approach that doesn’t leave lots of space for creativity, neither creativity nor UX need to fall short as Jongerius and Berghuis claim.

Sprint 0 should serve a space to plan and make space for all activities that do not necessarily find lots of time in later sprints.

The goal is to set up a clear vision, team support and strategy for the following sprints and the entire project.


Develop and Deliver meet Sprints and Loops

Creating hypotheses mentioned in the previous paragraph relates to the “Design / Ideation” phase of the “Revamped Double Diamond”. Gothelf considers…

…collaboration the most effective way to rally a team around a design direction, helping teams to build a shared understanding of the problem and solution.
Collab — after standing around walls you might want to sit down at some point

Following “Design / Ideation”, the “delivery” phase is about applying a “build-measure-learn” loop. This loop aims at minimising project risk and getting teams building quickly and learning quickly. Teams build Minimum Viable Products (MVPs) and ship them quickly to begin the process of learning as early as possible.

The goal is to test whether assumptions or ideas are viable to achieve an overall desired outcome.

Assumptions of potential solutions or hypotheses (set of ideas) should be made tangible and testable.

Eric Ries’s (2011) “build-measure-learn” loop (from “The Lean Start Up”) has been used in various process models. Depending on the model, source, or methodology namings might differ:

  • Create/Build/Prototype
  • Test/Research
  • Analyse/Measure
  • Learn/Iterate/Repeat

While “build-measure-learn” is a constant circular approach, scrum projects often consist of three to four sprints per project in this stage of the project, following sprint 0.


Team is everything

“Team is everything” is a core principle at Hyper Island. It is believed that…

…collaboration, inclusion and transparency are crucial to growth.
“If they are not A TEAM, who else? – Img Source Link

This principle is infused by practising and applying team building, team “maintenance” and team termination tools and activities.

The goal is to build and maintain a strong culture and therefore effective teams by fostering trust and openness for better collaboration.

Culture is a core component of successful teams and companies. As Brian Chesky states, airbnb got its $150m investment by Peter Thile partially thanks to their culture. His core take-away:

Don’t Fuck Up the Culture

Teams are also essential in an agile mindset. The agile manifesto puts “individuals and interactions over processes and tools”, and lists specific principles putting emphasis on team, collaboration and culture:

  • Close, daily cooperation between business people and developers
  • Projects are built around motivated individuals, who should be trusted
  • Face-to-face conversation is the best form of communication
  • Best architectures, requirements, and designs emerge from self-organizing teams
  • Teams regularely reflect on how to become more effective and adjusts accordingly

Gothelf advocates a high level of collaboration between different disciplines, too. He encourages conversation and sharing insights between representatives from each discipline to drive greater team efficiency.

Similarly,

Design Thinking is about the people you are designing for and the people you are designing with.

Conclusion

No matter what PM methodology you apply to a Human/User Design or Design Thinking process, “team and people are everything”, as…

…a final outcome of a project is usually tailored to improve the lives of people.

Applying the Revamped Double Diamond as a framework to tackle design challenges and overlaying it with project management methodologies is not contradictory. It may help when trying to implement the framework into “real world” practice.

As the agile mindset suggests, there is no fixed and exclusive way to execute project management or any specific method…

Teams and organisations ought to stay open and adaptive to cope with ever changing “real world” challenges.


Recommend and share this post if you like it and follow me for more



Credits & THX for collab on this article to: Daniel T Santos, Adrian Zumbrunnen, Caio Braga & Mahnaz Yusaf