Designing a great project environment


#1

What characteristics make a great project environment?

What elements should a project environment have to support the team to do great work?

Thanks,
Dan


#2

A few that come to mind:

  • Safe and Fair: give people the comfort to freely create, but hold them accountable for what they promise and for their responsibilities to the team
  • Tools at hand: have the things you need to do the work readily available, nothing kills your flow like having to search for supplies
  • Frequent (constant?) sharing: the work should be out in the space for all to see, discuss, and build on.

(this feels like a spin-off of http://discussions.ixda.org/t/preparing-an-organization-to-succeed-in-design/71/6)


#3

Thanks.

What artefacts need to be populated over time to ensure the core team is on the same page as it relates to the project story + the product/service being worked on? For example, goals, design principles etc


#4

I think the 12 questions from Buckingham & Coffman’s First, Break All The Rules are a good place to start:

  1. Do I know what’s expected of me at work?
  2. Do I have the equipment and materials I need to do my work well?
  3. Do I have the opportunity to do what I do best everyday?
  4. In the last 7 days, have I received recognition or praise for doing good work?
  5. Does my supervisor or someone in charge seem to care about me as a person?
  6. Is there someone at work who encourages my development?
  7. At work, do my opinions seem to count?
  8. Does the mission/purpose of my company make me feel my job is important?
  9. Are my co-workers committed to doing quality work?
  10. Do I have a best friend at work?
  11. In the last 6 months, has someone talked to me about my progress?
  12. In the last year, have I had the opportunity to grow and learn?

I think if we start with building an environment where these 12 factors get a solid YES! answer, then we’ve got a good start on a good working environment.


#5

Off the top of my head:

  • A clear vision — but one that the team owns so that they can pick a new north star if they need too
  • All the people in the same place at the same time — so that we don’t slow ourselves down by having to wait for others, produce artefacts purely to document/communicate, etc.
  • A externalised representation of where we are now, and what we’re doing next — so we can’t fool ourselves into thinking we’re aligned when we’re not
  • Frequent contact with the end-user(s) — at least once a month, preferably much more often. because, sanity
  • Frequent contact with other stakeholder(s) — at least once a month, preferably much more often.

#6

What artefacts need to be populated over time to ensure the core team is on the same page as it relates to the project story + the product/service being worked on? For example, goals, design principles etc

Hmmm… I get really suspicious of “standard” sets of artefacts. Since what’s the right set changes depending on the project and the team.

The artefacts that need to be populated over time are the ones the team decides that they need.


#7

Thanks Adrian + co.

So why a standard or common set?

We have observed that there are only a few documents in a project that help connect a project story and its members together. Sometimes these documents are hidden from view and difficult to understand.

So what if there were a standard or common set to get the project started? These can fit the specifics of the project over time, but the intention is to help connect a project together around its goals, customers, data and designs.

This may help provide a well understood story and speak to some the points already suggested.

It also implies a lead role in introducing the artefacts and guiding the project on how to populate them and how they should connect or speak to each other.

It seems not only organisations are in silos, but so are team members and the documents/deliverables they produce. This is not even talking to how well or not well designed or usable or useful these artefacts are to begin with as communication pieces and the language inside (inviting or divisional)

So how would we find simple ways to address this?

rgds,
Dan


#8

One way we’ve tried to address both of these perspectives is to have suggested artifacts as part of a project plan to give people a common sense of what types of things will be happening at each part of the project. This is a malleable and non-exhaustive list, so new ideas can be introduced any time or things can be left out based on current needs. The suggestions make the need apparent so that the team and stakeholders can at least have a conversation about expectations and put all of these issues out in the open.

We also make sure we discuss why or why not for different types of artefacts so that everybody is on the same page about what we’re aiming to get out of each thing we’re producing.


#9

Thank you and seems like there is a benefit to a project induction and understanding the UX of the project itself.

Have not really seen this done well and its been more of a learning on the job and then determining where you can help in the mess.


#10

Rather than a list of artefacts, I find it much more useful to focus on the particular problems we find at different points in the discover & development process. Those can then encourage us to dig into finding the right artefact to solve those problems depending on our context.

Knowing what we want should drive the selection of artefact (if any — sometimes artefacts aren’t the right thing to be making). Not the other way around.


#11

This is basically what I was getting at… We don’t necessarily have a “list” at the beginning, but we do have an idea of the questions we need to ask/answer first and what methods might help us answer those questions.

That response was also about a very specific type of situation. One where we know we will work best the way you suggest, but our client/partner requires some sort of “list of artefacts” to feel comfortable about the project and know what they can expect. It almost always changes as we go…


#12

Some thoughts here - http://www.uxmatters.com/mt/archives/2014/11/designing-projects-for-success-a-more-humane-ux-practice.php

rgds,
Dan


#13

It depends on the project. For few people it could be set of get-things-done utilities and new Instagram is done, great project, ain’t fun? For A380 it is different story, they used many advanced tools, such as CATIAs with different measurement units which led to big issues at assembly stage. So the question is too generic to be answered precisely. At high level it must be set of tools to ship what you do. One tool is not enough, but how many you need - it is exclusive question.


#14

Agree its contextual and perhaps the more projects we can learn from to see:

  1. How we worked
  2. How we want to work

The more libraries of experience we have to share on what tools are needed to make the project work well based on context.

rgds,
Dan


#15

This is a malleable and non-exhaustive list, so new ideas can be introduced any time or things can be left out based on current needs. The suggestions make the need apparent so that the team and stakeholders can at least have a conversation about expectations and put all of these issues out in the open


GuL


#16

Love of their work … and embracing the challenges
Clear vision … and communicating this vision
Strong team building skills … and setting positive tones
Structure and alignment … creating the environment and direction
Strong interpersonal skills … listening to and leading their teams
Discipline … completing each phase of the project properly
Communication skills…knowing when and to whom to communicate

( Come to my mind )


#17

Thank you and this is worth reading and watching - http://www.nytimes.com/interactive/2014/09/22/arts/music/kronos-quartet.html

rgds,
Dan


#18

This is such a fantastic website I will never see again.


#19

Less about the website and more about the story itself in terms of how each musician plays together and support each other in the making of the music.

rgds,
Dan


#20

You saw them in his music is awesome.