Tracy's DMP 2013 Weekly Tasks and Reflections

People ‘on the ground’ are your best asset

Perhaps not directly related to this project but very interesting from a management perspective is this article from the SMH online:

A few key takeaways that are pertinent to my situation at the moment:

  • Value diversity

Michael McQueen argues:

“The minute you look around at your team and everyone is of similar age, of similar background, you’re in trouble. At Daewoo, up until they collapsed, up to 70 per cent of their management team went to the same high school.

“So you’ve got this culture that forms that attracts people who are like what the culture already is. Anyone who comes in with a different mindset is ejected, like a white blood cell.

“Organisations often can’t see themselves and you look from the outside and say ‘you guys are so stuck in the way you do things, nothing has changed in the last three years, and you all look the same’, which is a big telltale sign.”

I can see this in action in my own working experiences. Management who only value people like themselves lose sight of what’s important and can’t see the forest through the trees. Part of the reason I wanted to do Interactive Multimedia Design instead of ‘e-Learning’ or ‘Instructional Design’ even though these are really the types of industries I want to be in, is because I wanted to offer something a little different and unique- to come at the problem from a different angle. I want to do online learning, and I know “learning” very well with my whole work history in “learning”, what I don’t know is the ‘online’ part. Even taking e-Learning subjects in the faculty of education has been a strange experience, the emphasis is very much on learning theory, the teaching modes, the way education happens online, but there is little interest in the interfaces, the affective user experience, design processes, the technologies and the development process. These elements are crucial to the success of an e-Learning project but, in my opinion, the e-Learning industry seems to be flooded with teachers and pedagogues, and not enough technologists so we only get half of the solution.

  • Listen to people on the ground

McQueen says there is no way to accurately predict how many companies may unknowingly have passed their peak and be heading into a period of decline, although it is often staff rather than management who see the first signs.

“Often the managers only look at the skin-layer indicators, like how are we tracking against the budget, what are our KPIs. But on the floor often it’s those staff who know because they talk to customers, and customers are saying ‘you’re overpriced’ or ‘your systems are outdated’, but it’s not filtering to to the top,” he says.

Ways of filtering up information about what is happening at the grass roots to management seems essential to ongoing success. I suppose that is very much the key to the User Centred design process- hearing from users, hearing from the people who are on the ground about what they need is key to continually producing innovative and relevant products. It seems to me that companies and organisations who use a User Centred design process will avoid being lured by the skin-layer indicators and will be more attuned to the indicators that keep you on the cutting edge of the industry.

Colquhoun, S. Is shiny Apple rotting at its core? Sydney Morning Herald, May 22, 2013 accessed at:

The Meaning of Work

I have spent a little time thinking about the conflict that had taken place half way through the semester and what it meant. It was also interesting to me because I have experienced a fair amount of conflict and challenges in my own work and structures of work, management and team work are in the forefront of my mind.

I had been sent a TED video presented by Dan Arielya on “What makes us feel good about our work?”

I was particularly interested in the example Dan gives about the experiment conducted on working subjects who are asked to build Bionicles. I located Dan’s experiment (Arielya et. al., 2008) and looked into it a little further.

In the experiment,

“subjects received payments for assembling Bionicle Lego models according to a declining unit wage schedule. Each Bionicle consisted of 40 separate pieces, with written instructions on how to assemble them into a figure. There was only one way to combine the pieces, and no subject had trouble following the assembly instructions. The mean time to build the first Bionicle was around 10 min. Before deciding whether to build each Bionicle, the subjects were told how much they had earned up to that point and how much they would earn for making another Bionicle. The subjects were paid $2.00 for the first Bionicle, $1.89 (11¢ less) for the second one, and so on linearly. For the 20th, as well as for any subsequent Bionicles, they received $0.02. The only decision the subjects made was when to stop making Bionicles. At that point, they were paid and the experimental session was over.

In the Meaningful condition, after the subject would build each Bionicle, he would place it on the desk in front of him, and the experimenter would give him a new box with new Bionicle pieces. Hence, as the session progressed, the completed Bionicles would accumulate on the desk.
In the Sisyphus condition, there were only two boxes. After the subject completed the first Bionicle and began working on the second, the experimenter would disassemble the first Bionicle into pieces and place the pieces back into the box.

Despite the fact that the physical task requirements and the wage schedule were identical in the two conditions, the subjects in the Meaningful condition built significantly more Bionicles than those in the Sisyphus condition. In the Meaningful condition, subjects built an average of 10.6 Bionicles and received an average of $14.40, while those in the Sisyphus condition built an average of 7.2 Bionicles and earned an average of $11.52. ”

This experiment gave me food for thought about both my work and the progress of the team. The key insight for me was:

Having your work dismantled before your eyes is soul destroying, and isn’t good for productivity

In the context of my work, I have experienced this, and it is very difficult to apply yourself to your work when it is seemingly done without purpose or result, or even acknowledgement. I think this is a very important insight for management- people gain satisfaction out of building useful and meaningful products and a good manager is able to acknowledge work, take interest in it, and value its creation.

Secondly, the challenge of management is to ensure work is of a high standard, aligns with business and project goals and will be useful and meaningful. The challenge of working in teams, and supervising teams, is working to get the best out of people and ultimately creating a successful product. In the context of this project, the difficult thing for me has been to strike a balance between taking interest in others’ work, trying to provide constructive feedback and to critically evaluate others’ work without dismantling it before their eyes. How can you be critical and offer suggestions for improvement without compromising the motivation and investment the team has in the process? This has been hard. There have been situations where I have felt the team is on different pages and individual’s work needs to be changed and aligned to become more cohesive, or needs to be improved. Yet they have worked hard, have a lot more work to do outside this project and redoing it is upsetting and frustrating. I think I have been more careful about the feedback that I give, the way I give it and to be more sensitive to the pride team members feel about their work. And to realise that my feedback is my opinion and isn’t always right.

Alongside this is a realisation that trusting other team members to get the job done, even if it’s not the way I would do it, is paramount to success and team cohesion. Perhaps I’m guilty of expecting my team to build the Bionicle the way I think it should be built. It’s hard to let go when it’s important the team is successful. Trust is hard, especially when team members seem to be on different pages and communication is floundering, when we have different strengths and tackle things in different ways. It’s also hard to be ultimately responsible for the success of a project and to fear the team members you are supposed to be managing might not deliver at the quality and quantity that’s expected. This fear probably breeds micromanagement and it’s a hard lesson to be accused of micromanagement when, in my own work, I’m on the receiving end and all I want to say is; “trust me, I’ve got this”.

Ultimately, backing off from the team, being aware of what I’m doing and trying to strike the balance of providing feedback, ensuring the team is on the same page and handing over control and direction has made for a much better team environment and probably a much better product.

The researchers of this study concluded;

“The work presented here also sheds some new light on the relationship between monitoring and effort. Many researchers, such as Falk and Kosfeld (2006), have suggested that close supervision of workers might undermine intrinsic motivation. Our Experiment 1 suggests that the way in which monitoring is framed crucially influences its effect on motivation. If perceived as interest in the worker, supervision might improve worker morale rather than induce a feeling of lost autonomy. Thus, monitoring that is accompanied by increased meaning (recognition, education, acknowledgment) might not only eliminate the negative side effects of control, but also increase workers’ effort and motivation.”

Arielya, D., Kamenicab, E.,  Prelec, D. Man’s search for meaning: The case of Legos Journal of Economic Behavior & Organization 67 (2008) 671–677

Lessons in PHP

This post comes after a victory in some php coding to work with making the ‘points’ feature useful in Ushare.

The team decided the rank a user has should be displayed in their Cubepoints sidebar, profile page, under the site logo and the Avatar bubble. Also, the site logo should change depending on their rank, and their rank image should be displayed in the sidebar.

This has been a little tricky for my poor coding skills, but I got there in the end.

1. Changing the logo

After some searching the WordPress site and Googling, I found some examples of displaying Cubepionts content.

This thread got me started on how to work with Cubepoints in templates:

I started with working on getting the points of the currently logged in user and displaying those points. Once I could do that, I could build some logic. If a user has points between X and Y, display this logo. If a user has more points that Y, display a different logo.

The code is:

$current_user = cp_currentUser();
$points = cp_getPoints($current_user);
$rank = cp_module_ranks_getRank($current_user);

if ($points > 0 && $points < 51) {
?><img src=”<?php echo home_url(); ?>/wp-content/themes/neuron/images/glasses.png” height=”70″><?php
} elseif ($points > 50 && $points < 101) {
?><img src=”<?php echo home_url(); ?>/wp-content/themes/neuron/images/baseballCap.png” height=”70″><?php
} elseif ($points > 100 && $points < 201) {
?><img src=”<?php echo home_url(); ?>/wp-content/themes/neuron/images/mortar.png” height=”70″><?php
} elseif ($points > 200 && $points < 501) {
?><img src=”<?php echo home_url(); ?>/wp-content/themes/neuron/images/hatAndMoustache.png” height=”70″><?php
} elseif ($points > 500) {
?><img src=”<?php echo home_url(); ?>/wp-content/themes/neuron/images/crown.png” height=”70″><?php
} else {
?><img src=”<?php echo home_url(); ?>/wp-content/themes/neuron/images/ushare-logo.png” height=”70″><?php

This code does the job for now but it’s not going to be sustainable. It manually sets the windows for changing the images and doesn’t directly correspond to any ranks. Ideally, the plugin would be enhanced by adding another Cubepoints Field for the image. A user could upload images for each rank in the admin panel at the point where the administrator chooses rank names and point thresholds. Then you would call the rank image as well as the rank in the template. This coding was a little beyond my skills, but I’m happy to get to the point where I can swap out images for different thresholds of ranks.


The sentence under the logo was easy at this point because all the variables had already been stored. It was just a matter of printing them.


2. The Avatar Bubble
The avatar bubble was a bit harder. Getting the points of the currently logged in user wasn’t too hard. Cubepoints just uses “cp_currentUser()” to get the ID of the current user. But this plugin requires you to find out the user ID of the avatar you have hovered over. Searching through the code to find out how the plugin did this and trying a few things resulted in a few fatal errors. It wasn’t too difficult in the end- the plugin had already pulled that data and stored it- it was just a matter of reading the code and trying to find it. A bit more Googling and this thread:, helped me out.


3. The Profile Page

The hardest part about this was finding the code that prints the points and rank on the profile page. Once again, I needed to find out how to collect the user id of the profile- different to the avatar bubble, and work with it. I couldn’t quite get to the point of printing the users rank image. This is where it would have been beneficial for it to be stored in its own variable. I might see if I can work on that before it’s done!



Isolating and Prioritising Features

Another aspect of feedback this week was to consider looking into the methods for Agile development, and specifically how features can be prioritised based on User Stories. This isn’t something I know much about, so I’ve looked into both Agile Development and the many methods for prioritising development.

Agile Development

Agile development is about:

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

One of the key ideas in Agile development is changing requirements and needs and responding on short time scales. It is also about continually developing and improving software.

Agile Alliance :: The Agile Manifesto [WWW Document], n.d. URL (accessed 3.24.13).

Most versions of agile development have a prioritisation phase that delineates which features or aspects of development will be included, and then a development phase, in which developers commit to developing the prioritised features. This allows for a constant evolving and changing product.
One such method is the Scrum method, where teams have a prior meeting to determine priorities, then follow this with a Development Sprint. Another method is Feature Driven Development,  which begins with establishing an overall model shape. Then it continues with a series of two-week “design by feature, build by feature” iterations. The features are small, “useful in the eyes of the client” results. Unlike other agile methods, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.
A third method, Dynamic Systems Development, operates as follows:

Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:

M – Must have requirements
S – Should have if at all possible
C – Could have but not critical
W – Won’t have this time, but potentially later

All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.

Agile Methodology – Agile Methodologies for Software Development [WWW Document], n.d. URL (accessed 3.24.13).

Prioritising Development

I’ve come across a number of techniques for prioritising development, and Berander and Andrews (2005) offer the best summary for the range of techniques, their uses and benefits/ drawbacks. A summary of their paper follows:

When prioritising, it’s important to understand what factors you are using to generate priorities  There are six main areas to consider: Importance, penalty, cost, time, risk and volatility


1. Analytical Hierarchy Process (AHP)

AHP is conducted by comparing all possible pairs of hierarchically classified requirements, in order to determine which has higher priority, and to what extent (usually on a scale from one to nine where one represents equal importance and nine represents absolutely more important).

2. Cumulative Voting, the 100-Dollar Test 

The 100-dollar test is a very straightforward prioritization technique where the
stakeholders are given 100 imaginary units (money, hours, etc.) to distribute between the requirements. The result of the prioritization is presented on a ratio

3. Numerical Assignment (Grouping) 

Numerical assignment is the most common prioritization technique. The approach is based
on grouping requirements into different priority groups (e.g. critical, standard, optional).

4. Ranking

As in numerical assignment, ranking is based on an ordinal scale but the requirements are ranked without ties in rank. This means that the most important requirement is ranked 1 and the least important is ranked n (for n requirements).

5.  Top-Ten Requirements

In the top-ten requirements approach, the stakeholders pick their top-ten requirements (from a larger set) without assigning an internal order between the requirements. This makes the approach especially suitable for multiple stakeholders of equal importance.

The following table outlines the scale, granularity and sophistication of each technique:

Prioritise techniques

Berander, P., Andrews, A., 2005. Requirements Prioritization, in: Aurum, A., Wohlin, A. (Eds.), Engineering and Managing Software Requirements. Springer Verlag.

If we are to use an Agile approach, using a simplified version of AHP might be a good strategy for us.

Stuart (2008) uses an adapted model, which produces prioritised requirements by a 2×2 scale as shown below:


Stuart, J., 2008. Early Requirements Prioritization Technique: Best Practices White Paper. Construx Software.

Getting a bit tangled…

I’ve felt a bit tangled this week…

I feel like I’ve needed to do a bit of back pedalling when it comes to deliverables vs documentation vs phases to try and make the project management clearer and more precise.

The feedback given this week was to work backwards from delivery date and have a proper project plan. I thought I had a project plan, but it’s starting to get a little confusing. The deliverable items in Podio have really been items for documentation, not deliverables as such. But the tool has really been trying to serve both purposes: manage the tasks the team has to do and manage the documentation the team has to do. It’s now not doing a very good job of either. This has meant I’ve needed to do some refining of the tool to make it easier for the team to track their tasks and to map out dependencies.

The Workshop

We had a workshop yesterday with the team. The workshop had been planned for a couple of weeks and it was intended to be a way of bringing all the user research together and formulate a strong plan of action for the site.

The goals were as following:

  • Share our findings of our user and market research
  • Analyse data, identify patterns and start to draw conclusions
  • Find insights from our research that are interesting, surprising and pertinent
  • Understand the needs and concerns of our users and what gaps can be filled
  • Generate ideas to meet the needs of our users
  • Start to narrow down exactly what we want our product to be, what features it will have and how we can do this well
  • Start to narrow down technical, functional and design goals and approaches

We used a range of techniques for analysing and synthesising research data, generating ideas and narrowing down solutions. The three broad areas for work were:

  • Knowing our users and market
  • Generating Solutions
  • Narrowing Solutions

The aim was to have an Elevator Pitch by the end of the day.

10:00-10:15: Establish goals and rules

Starting the day by establishing goals and rules was important. Anderson, 2011 suggests clearly stating the objectives of the day helps everyone understand the context of the creative activities that will follow. Framing of the problem to be solved is important if participants are to stay on track, it’s important to draw some hard boundaries within which everyone is encouraged to play. The rules were collaboratively developed and included rules about keeping on track and on time, listening to others and creating a positive working environment.


Knowing our Users and Market

11:00-11:30 Affinity Diagram

All team members had completed various forms of user research and done some version of synthesis of their results. We each took post it notes and wrote down key insights from the research we had brought with us. It was important the insights came directly from the research. Team members wrote down lots of insights, from varied angles. Then the team presented their post-its to the team. As team members presented, we started to group the post it notes according to emerging themes. The benefit of this was being able to quickly get across all the research done by other team members and easily see emerging themes. It was both visual and auditory so the team could process the information as they heard it, then come back to it as it was organised on the board.

The method for constructing the Affinity diagram was adapted from Mindtools and the benefit was also exactly as described:

Affinity diagrams are great tools for assimilating and understanding large amounts of information. When you work through the process of creating relationships and working backward from detailed information to broad themes, you get an insight you would not otherwise find. The next time you are confronting a large amount of information or number of ideas and you feel overwhelmed at first glance, use the affinity diagram approach to discover all the hidden linkages. When you cannot see the forest for the trees, an affinity diagram may be exactly what you need to get back in focus.

Affinity Diagrams – Problem-Solving Training [WWW Document], n.d. Mind Tools. URL (accessed 4.3.13).
Empathy mapping
The empathy map was about synthesising our research and the work we had done for the Affinity diagram to focus on our users- what they say and do, what they think, what they hear and see and their ‘pains’ and ‘gains’. This was a great activity to get us acquainted with our users and start drawing connections with the research and the humans behind it. The Empathy Map strategy was suggested by Jax, but also had been seen in the Standford Design School materials.
Plattner, H., 2010. Bootcamp Bootleg [WWW Document]. URL (accessed 3.3.13).


Journey Map

The Journey Map was about helping the team to understand the process of doing an assignment for university- to empathise with the users and to identify takeaways or opportunities that we could harness in our design to create a useful and well-targeted product. The takeaways that were generated as we isolated each step in the process were really valuable for moving forward.

Flom, J., 2011. The Value of Customer Journey Maps: A UX Designer’s Personal Journey [WWW Document]. UX Matters. URL (accessed 3.4.13).


While this wasn’t initially on the schedule, we decided to bring the development of the Personas into this workshop as we felt it would be valuable to do this as a team. Some great discussion was generated around  ‘who’ our audience was and it also identified a few gaps in our research that we felt a survey might be able to be used as a good follow-up research technique.


Design Principles

Even though our time keeper was great, we didn’t get to the design principles as we were running out of time and felt we needed to move onto concrete solutions so the team could keep working after the workshop. This was ‘parked’.


McDonalds and bonding! We were going to go out but the team chose to work through lunch as we were ‘on a roll’. It felt good the team weren’t bored and were finding the techniques valuable.

Elevator Pitch

We jointly developed the elevator pitch to narrow down our focus and be very specific about the product we were building. This made it much easier to come up with useful and targeted solutions later in the afternoon. We found the semantics of this task difficult!


Brainstorming and Brain Building

Brainstorming was about generating as many ideas as possible and putting them down on paper. Many team members had come up with ideas in the morning sessions and wrote them down on post-its as they came up. We spent about 10-15 minutes silently writing down our ideas, then we started talking about them and organising them. Once the ideas stopped flowing freely, we tried ‘Brain Building’- taking one team member’s idea and building on it by adding  a feature, improving it in some way or providing some clarity about how it might work


Problem Redefinition/ POV Madlib

This technique was adapted from Polczynski’s course materials on Strategic Technology Management and Stanford Design Schools POV Madlib technique. The idea is basically to redefine the problem by creating a problem statement and substituting phrases and words that narrow down the problem or make it more specific. This helps to think about the problem from a different angle and come up with solutions that are for those particular circumstances. It was a great method for refining ideas.

Polczynski, M., 2009. Strategic Technology Management – Reference Materials [WWW Document]. URL (accessed 3.24.13).

Concluding the Day

By the end of the day, we had an elevator pitch, quite a few questions answered and the scope narrowed somewhat. It was a good outcome! Everyone was tired, but after a difficult week for the team, it was a really positive end and made it easy to move forward to the next step.

Handling Conflict

There has been some team conflict this week and it has been an interesting challenge to work through that conflict to get to a result the team is comfortable with.

The scope of the project was too big, and decisions needed to be made about which aspects to focus on in order to move forward. A meeting was called to discuss scope, but not all team members could attend. A few team members talked about a new direction they wanted to take and presented the idea to the team a few days later. Some of the team were not happy with the new idea as it was presented, and other members of the team were frustrated at the lack of acceptance, wanting the decision to be made so next steps could be taken. In the course of the meeting, team members presented their ideas, the ideas were discussed and some aspects challenged, the idea started to evolve and the meeting ended with a hybrid concept of the team’s positions which was written down and agreed to. I think the team came out a little frustrated at the long meeting and difficult process of compromise, but I also think it was a successful outcome for what could have been a breaking point in the project as team members had strong opinions and feelings.

Reflecting on this experience, some things I think we did very well:

  • Everyone was given a chance to express their opinions and defend their position respectfully, and everyone did contribute to the debate
  • Each team member was finally willing to compromise and move past their own, strong opinions (myself included, I hope!)
  • After a long discussion about the merits of the ‘new’ idea vs the ‘old’ idea, team members started making suggestions about how to combine the best of both ideas to ensure we didn’t throw away work we had already done, but so it took a direction other team members were happy with
  • We finalised an idea, with features or aspects we could all agree on, wrote it down as a team, checked back for agreement
  • Agreed on next steps and ensured everybody felt they could move forward and keep working based on the new direction

Reading about conflict resolution, I feel quite proud we ticked off most of the guidelines for effective conflict resolution:

  • Dealing with conflict immediately – avoid the temptation to ignore it.
  • Being open – if people have issues, they need to be expressed immediately and not allowed to fester.
  • Practicing clear communication – articulate thoughts and ideas clearly.
  • Practicing active listening – paraphrasing, clarifying, questioning.
  • Practicing identifying assumptions – asking yourself “why” on a regular basis.
  • Not letting conflict get personal – stick to facts and issues, not personalities.
  • Focusing on actionable solutions – don’t belabor what can’t be changed.
  • Encouraging different points of view – insist on honest dialogue and expressing feelings.
  • Not looking for blame – encourage ownership of the problem and solution.
  • Demonstrating respect – if the situation escalates, take a break and wait for emotions to subside.
  • Keeping team issues within the team – talking outside allows conflict to build and fester, without being dealt with directly.
Resolving Team Conflict – Team Management Training [WWW Document], n.d. Mindtools. URL (accessed 3.17.13).

Some of the things I think the team (myself included) could work on:

  • This felt like a bit of a hijack- a couple of team members felt that if others weren’t at the meeting, then they missed out and the team needed to make a big decision without them. I don’t feel this was a good approach the problem- a big decision needed everyone there to participate and the meeting could have been postponed. As PM, I could have called the meeting at a time when everyone was available and made sure everyone knew the agenda, avoiding the ‘bomb drop’.
  • Not everyone was on the same page. I wasn’t worried about scope because I had felt the User Research would help to limit scope. Other team members felt the scope needed to be limited immediately in order to do User Research. Also, the team had very different ideas about what the initial idea was. There clearly wasn’t good enough communication and discussion about the initial idea, especially with newer team members. This could have been headed off with more conferencing about what the idea was in the beginning.
  • Backing down. If I believe in something, I do have trouble backing down, and it was hard to let my idea go, especially when I think another approach is really going to be unsuccessful. I found it frustrating that other team members didn’t ‘think like me’ or see it the way I did, or (the worst for me!), didn’t care what we did, as long as we chose something. It was a lesson in humility and compromise.

A week of research…

This week has been all about research. The team is working on strategies for gathering information about our users and the market context.

I realised a little too late that we had launched into choosing strategies for user research before we had really nailed the goals and areas for inquiry. We had touched on it at the Thursday meeting, but it was clear the team wasn’t on the same page and there were a lot of unanswered questions that needed to be discussed. As a result, the team was (not surprisingly) struggling to design the methods successfully. It was a really useful exercise to spend some significant time isolating the problem…

How can we make online learning a more engaging, motivating and effective space for higher education students?

…and identifying significant areas of inquiry:

Online behaviour, The learning experience (both offline and online) and enjoyment, efficacy and motivation

Focusing the group in this way has made me feel a lot more comfortable about the quality of data we are likely to get back from all of the strategies we are employing.

Thinking about reducing stress

Coming into this project, a number of the team members had indicated stress at the beginning of the semester. Asking about why they felt that way, the responses were around having so much work to do and not knowing what to do, adding and losing team members and not feeling like they are able to cope with the tasks because of skill gaps. I had found in my own experience that minimising confusion, breaking down tasks into manageable chunks and implementing strong processes were essential for me personally to reduce stress, regardless of the reasons why I was stressed. I find stress paralysing and I find the only way to rise above it is to fall back on techniques that  force me to move forward. With this in mind, I would like to help create a team environment that minimises the stress levels. I think it’s particularly important because we want to be a creative team and stress negatively impacts on creativity (Reily, 2012).

Nicholas (2004) cites common reasons for workplace stress:

  • Work overload, work underload: having too much work, as well as having work that exceeds a team member’s skills and abilities.
  • Role conflict: This happens when a team member receives contradictory or incompatibile expectations about their role, or they are required to do something that they don’t feel comfortable doing.
  • Role ambiguity: This results from inadequate or confusing information about what a team member needs to do to fulfil their role. It’s stressful because the team member knows neither where they stand or what to do next.
  • Social relations: Conflict, or team members who interact in ways that affect the team dynamics negatively can be damaging and stressful.

With these in mind, I’ve been trying each meeting to:

  • Check in on tools and processes, and find out if they are working. As an example, documents in our shared folder were getting out of control- information was hard to find, URL links were changing and the folders were confusing. This meant I found it hard to be across what everyone was doing, and the team couldn’t find the information they needed. This type of situation adds confusion, and thus stress to the project. The way the folders had been set up wasn’t working and I could anticipate the problems it would cause when it comes time to compile them into one cohesive document. A tool (Google Drive or Podio) isn’t enough to keep everyone on the same page. Ensuring processes are discussed, monitored and refined is more important than the tool that is used, according to Hamilton et. al. (2011).  While project management processes are not particularly interesting for the team, I am learning that they are important none the less.
  • Touch base with team members and find out how they are feeling, and why. One team member indicated stress because she was finding an aspect of her task difficult and she didn’t know how to tackle it. We were able to talk it out, find some resources together and I think it made it easier for her. Another team member said she was feeling a lot less stressed because she knew what she had to do. I felt this was a win!
Hamilton, G., Byatt, G., Hodgkinson, J., 2011. Understanding project management processes and tools to drive success [WWW Document]. CIO. URL (accessed 3.10.13).
Nicholas, J.M., 2004. Project Management for Business Engineering: Principles and Practice. Elsevier.
Riley, L., 2012. Effects Of Stress On Creativity [WWW Document]. Design Taxi. URL (accessed 3.10.13).

Work In Progress

This week, I have spent quite a bit of time trying to work on a project plan. I feel that strong planning up front, strong team expectations and removing ambiguity takes the stress and pressure out of team work. I know the team has already been stressed about the amount of work, the size of the team, the tight timelines and the difficulty of knowing where to start. I feel that since they have allowed me to project manage, developing a strong plan from the beginning can help the team to feel better about moving forward. As a smaller team (in the holidays), we had talked about using Garrett’s (2003) Nine Pillars as a framework for organising the project. We were all familiar with this framework from the DMDP course. Another team member had also recommended using Standford Design School’s methods, mindsets and design process- so I have been reading up, mainly using their ‘Bootcamp Bootleg’ resource (Plattner, Nd). The final resource that has been useful in developing a project plan comes from a project management perspective. The Project Management Institute produces the “PMBOK Guide” (PMI, 2008)- a handbook for project management using their recognised methods and processes. This has been useful tool for crafting a project management plan.

Garrett’s Nine Pillars:

Garrett’s Nine Pillars of Successful Web Teams, Accessed from

The design process SDS use consists of:

SDS Design Process, Accessed from

The other interesting resource is their mindsets, which I think could be very valuable for our team:

PMBOK’s Project Management Planning:

Developing a Project Management Plan, (PMI 2008, p.47)

Developing a Project Management Plan, (PMI 2008, p.47)

Using these models and the particular needs and constraints of this project, we have suggested working on a modified process which will work for this project:

Plan- Empathize- Define- Ideate- Clarify- Design- Prototype- Test

Using this process, all the tasks can be divided up into these phases and the tasks can be spread across the team- according to interest and need, but also so that we can ensure all team members can be working in all phases of the project so it can be delivered on time.

Garrett, JJ 2003, The Nine Pillars of Successful Web Teams. Accessed from

Plattner, H Nd. Bootcamp Bootleg. Accessed from

Project Management Institute 2008, A Guide to the Project Management Body Of Knowledge (PMBOK Guide) 4th Ed. PMI, Pennsylvania