Edwina Nolan Hyper Island DXD Crew 1
MANAGING PROJECTS A Critical Reflection
CONTENTS PROJECT MANAGEMENT IN THEORY
5
Introduction
7
Definition of Project Management
7
Traditional and emerging models of Project Management
9
Agile Project Management
13
Scrum Project Management
14
Using Lean to Enhance Agile Project Management Methodologies
16
PROJECT MANAGEMENT IN PRACTICE
21
Issues Encountered During Team Projects
22
Practical Skills Needed for Managing Projects Effectively
26
Ethical Issues in Team and Project Management
30
Conclusion
33
BIBLIOGRAPHY
37
PROJECT MANAGEMENT IN THEORY An overview of the different frameworks of Project Management and their practical uses.
INTRODUCTION DEFINITION OF PROJECT MANAGEMENT Project management has its origins in several different fields of discipline, (Molhanec, 2007) and as a result many definitions exist. The most relevant for me is from the Association for Project Management which defines it as “the application of processes, methods, knowledge, skills and experience to achieve a project objectives” (APM, 2015). It is a temporal activity and objectives must be achieved within a specific time frame (Wei et al, 2013). This specific time frame is a key factor in distinguishing it from plain management (Naybour, 2014). The results of a project-managed project can be tangible or intangible, from a physical product or software, to a service or organisational change. Although the parameters of the goods might change, the aim are always the same: to “effect some change for the benefit of the organisation that instigated the project” (Naybour, 2014), in the shortest time possible and “with the minimum use of resources” (Wei et al, 2013).
Time
Scope
Quality
Cost
Project Management Triangle or Project Management Triple Constraint (APM, 2015) Experience Design Exploration - DXD Crew 1 October 2015
Page 7
Angela Clarke proposes four factors that contribute to a successful project execution: “complete communication, clear objective and scope, adequate project partition, and use of management documents” (Clarke, 1999). Research findings confirmed the adoption of a project management approach increases the likelihood of project success, as well as offering the best value for businesses and higher satisfaction amongst stakeholders (APM 2015). Project management is no longer being seen as a “tool” but more as a holistic approach (Svejvig and Anderson, 2014) to “organisational efficiency, effectiveness and innovation” (Jugdev et al, 2003). Successfully project-managed teams, benefit from increased productivity, innovation and employee satisfaction (Moe et al, 2009). As part of this essay I will discuss the different approaches to project management from traditional to more emerging practices such as agile and lean. I will also look at the benefits and issues arising from these forms of project managements. I will also touch on the practical skills required to manage a project effectively and how all of these skills, approaches and learnings from previous experiences will ultimately feed into my Industry Research Project.
Managing Projects - A Critical Reflection October 2015
Page 8
Highbury Stadium, 2006
TRADITIONAL AND EMERGING MODELS OF PROJECT MANAGEMENT Prior to Hyper Island I had very limited experience of set project management, but reflecting on my previous work experience in studios and workshops, I can clearly see we were working in a Waterfall style of project management. Waterfall is considered to a traditional approach to project management and has a clear “command-and-control� style in which each role is clearly separated, tasks are completed sequentially, feeding into each other in a downward fashion (Moe et al, 2009), hence the name. This approach is very hierarchical (Moe et, 2009) and allows little delineation from set tasks. It is made up of four very clear stages: initiation, planning and design, execution and production, monitoring and controlling, and completion and testing (Molhanec, 2007). Each stage must be completed prior to moving on to the next stage. Waterfall project management works well when the requirements are known upfront and unlikely to change, and there is little uncertainty (Bowes, 2014). Industries like engineering and construction work well within this style of management for these reasons. Waterfall is criticised for not being very customer-centric or adaptable to change. As testing occurs at the end of the cycle, customer requirements may have changed or are not being met by the solution (Pope-Ruark, 2014). Amends at the this point can be costly, time-consuming and frustrating for design staff (Pope-Ruark, 2014). It also does not handle ambiguity at the front end of a project well (Bowes, 2014), so is very unsituated to a human-centred design approach where uncertainty at the beginning of projects is inevitable.
Managing Projects - A Critical Reflection October 2015
Page 9
SET SPEC
(Model and Plans)
METALWORK (Set Frame)
CARPENTERS (Frame Cladding)
FINISHING
(Texture and Details)
SCENIC ARTISTS (Painting and Finishing)
Overview of the “Waterfall” Workflow in Capital Scenery
Early in my career, I worked for a theatrical production company in London, finishing and painting sets. We worked mostly for Operas and West End productions. We would be contracted by these companies to construct their sets. The sets would have already been designed by a theatre designer outside of our studio. As you can see from the workflow diagram, we worked very much in a traditional “Waterfall” approach. The scope of the project was defined prior to arriving on the workshop floor, in the form of plan drawings and often a maquette model. The workshop was very clearly divided into different disciplines: metalworkers, carpenters, finishers, painters. These teams were overseen by the studio manager, Roger, who would also act as project manager.
The work would flow “downstream” to each of these teams. As already stated this linear form of project management works well in construction-based projects (Wernham, 2012). The metalworkers would produce the set frames which the carpenters would clad in chipboard. The chipboard would be passed on to the finishers for texturing, before the painters would complete the job.
Managing Projects - A Critical Reflection October 2015
Page 10
As also discussed, the drawback to this way of working is should any of the specifications need to change it was costly and time consuming (Pope-Ruark, 2014). This though was generally not the case, as we were outside contractors any amends “out of scope”, i.e. not already in the drawings, would be additionally charged for. The practical drawback with this way of working was time was always short on the end. The money saved on fixed scope was often lost in overtime costs. If carpentry or metalwork went over time schedule by a few hours each, this would affect the finishers and painters, often resulting in very long hours and higher staffing costs (in overtime) in a bid to “get the job done”. This style of project management largely worked well for us but would not have worked during the more complex and uncertain project briefs set by Hyper. We would need a more adaptive and Agile approach.
Roger the Workshop Manager (looking a tad confused).
Vans Project Team at work
AGILE PROJECT MANAGEMENT In 2001 a group of seven software developers published The Agile Manifesto, their project management ideology. (PopeRuark, 2014) The manifesto states:
“We should whenever possible; value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.” (Beck et al, 2001) These developers created the Manifesto as a way to create software “in a lighter, faster and more people-centric way” (Molhanec, 2007). Agile responds well to uncertainty acting as an “evolutionary conversations” with users. Instead of building the whole product, “you build the smallest possible useful part and give it to users, who tell you what is right and what is wrong” (Woods, 2010). Agile is divided into five main phases: initiate phase where the project is defined; construct phase where the product is built; deliver phases release of the product; maintain and support phase, where the delivered product is kept up to date and improvements made from feedback (Molhanec, 2007). Each of this phases are completed in sprints or timeboxed events. In contrast to Waterfall’s “command-and-control” style of management, Agile has more autonomous leadership style, focusing on the collective team. It is a plan-driven framework consisting of independently self-managing professionals (Moe et al, 2009). At the time of its introduction Agile was a radical shift from Waterfall, giving the team “the full authority to do whatever it decides to achieve the goal” (Moe et al, 2009).
Experience Design Exploration - DXD Crew 1 October 2015
Page 13
SCRUM PROJECT MANAGEMENT Scrum is of the most popular Agile management practices. Created by Ken Schwaber and Jeff Sutherland in the early nineties, it incorporates the Agile principles of “a faster, more reliable, more effective way to create software” (Sutherland, 2014, p.6). Scrum uses iterative and incremental work practices in timeboxed frames (Zhi-gen et al, 2009). Put simply, a team is given a list of product or software features they need to deliver. The team then divides and prioritises these tasks, working on them in sprints of between 2-4 weeks. The Scrum team consists of a Product owner, the ScrumMaster and the development team. THE SCRUMMASTER • Facilitates the design process • Ensures the development team can work without hindrance or obstacles • In charge of daily standup meetings (Daily Scrums), usually 10-15 minutes in length where tasks are briefed, completed task discussed and any impediments the team will foresee tackled. • Also in charge of Sprint Backlog (the overall task guide for the Development Sprint) and the Sprint Retrospective (review session at the end of the Sprint cycles) • The ScrumMaster also liases with The Product Owner THE PRODUCT OWNER • Represents clients interests • Oversee the products aims or product vision • Prioritise the “most valuable work” in the Product Backlog (Sims et al, 2014, p.8). • Responsible for ensuring that the team understands the requirements of what is to be built (Sims et al, 2014, p.8). THE DEVELOPMENT TEAM • Self-managing unit made up of designers, developers and strategists. • Producing the product or software, facilitated by the ScrumMaster.
Managing Projects - A Critical Reflection October 2015
Page 14
The Scrum Process (Polczyk, 2009)
AGILE VS WATERFALL The benefits of working in an Agile over Waterfall framework include better collaboration between staff, teams, clients and the customers they are representing. The iterative nature of the process improves quality in the final piece, as defects are exposed immediately instead of during the testing phase at the end (Woods, 2010). As a result of a work atmosphere that “fosters both accountability and personal and professional growth” (Pope-Ruark, 2007), Agile practitioners tend to be “happier, more engaged...and more innovative” (Grant, 2013). Toyota’s agile team approach achieved, “four times industry average productivity and twelve times better quality” (Pope-Ruark, 2007). As it adopted by more organisations, and methodologies become more sophisticated it is no longer being seen as a “tool” but more as a holistic approach (Svejrig and Anderson, 2014) to innovation, team management and organisations
Managing Projects - A Critical Reflection October 2015
Page 15
But Agile does not come without drawbacks. Adapting to Agile requires a shift in “mindset and management practices” that can be difficult to implement in more traditionally managed organisations (Pope-Ruark, 2007). This “self-organisation and intensive collaboration” can often be resisted by developers who are used to working on their own on tasks delegated by a project manager (Pope-Ruark, 2007). Initially, Agile can be costly to implement and requires much buyin from management and staff, and clients who have to take a more active role in the feedback process. It can also be difficult to implement at scale, having 20 teams working on the same problem or features proves difficult to synchronise findings and iterative workflows. Many leading product studios such as ustwo and Edenspiekermann would argue that the benefits far outweigh the drawbacks, stating they would not work in any other way. Collin Lyons, Projects Director at ustwo and Agile Coach, believes Agile is “going to create discomfort – but at ustwo we still believe it’s the most effective route to failing fast and, ultimately, delivering the product your customers wants” (Edwards, 2015).
USING LEAN TO ENHANCE AGILE PROJECT MANAGEMENT METHODOLOGIES For our final project our Industry Leader, Lawrence Kitson (Product Lead at ustwo), introduced us to their project management methodologies. The basis of ustwo’s approach was in Agile with the introduction of some additional Lean tools “to create maximum value for customers” (Maurya, 2012). Lean and Agile methodologies have their founded principles in the Toyota Production system (TPS), later called “Lean Manufacturing” (Fichtner, 2013). The principles of Lean are to “Eliminate Waste”, “Build Quality In” and “Deliver Fast” (Fichtner, 2013). Lean focuses
Managing Projects - A Critical Reflection October 2015
Page 16
Build
Measure
Learn
Lean Startup Methodology (Luong, 2014) more on principles than on practices. Lean is used to help build and define a marketable product. Agile is the management practice through which this is achieve (Kodukula, 2013). Lean is similar to Agile as the focus is features of the product, rather than the whole product (as in Waterfall). Lean narrows this focus even further by selecting, planning, developing, testing and deploying one single feature before repeating the process for another. In this way, risk is isolated to a feature level (Lee-Whitaker, 2010). This way of working reduces unknowns and “waste”, creating value for the company through the elimination of useless meetings, task and documentation (Fichtner, 2013). Through use of Lean principles, my team were able to produce an app within four weeks. I feel that adapting to a mixture of Lean and Agile methodologies allowed us to do that. We were able to “eliminate waste”, by testing a hypothesis and using iterative prototyping and user feedback to allow our customers to help define our minimum viable product (the product with the highest return on investment versus risk) (Ries, 2011).
Managing Projects - A Critical Reflection October 2015
Page 17
Using User Story Mapping (Patton et al, 2014) to identify and prioritise customers needs in order to “Build Quality In” and “Eliminate Waste”
By identifying our MVP, we were “Building Quality in”; creating something that people identified as desirable. We used the MVP and User Story Mapping (a process of defining and prioritising the products desirable features. The list of features are divided into releases which became the focus of sprints) (Patton et al, 2014). The customer gets the best version of the product available at that time, the very foundation of Agile and Lean Methodologies. Through a combination of these first two principles, we “Delivered Fast” and were able to complete four rounds of prototyping including a workshop in less than two weeks, in order to define our marketable product.
Managing Projects - A Critical Reflection October 2015
Page 18
AGILE VS LEAN The topic of Agile over Lean project management and vice versa, has received much debate in the last few years. Some are of the belief that Lean is merely a set of tools and Agile is a mindset and thus more valuable (Shalloway, 2009). Others state that Lean trumps Agile because of its scalability, allowing multiple teams work together on a project with easier synchronisation of iteration cycle results and feedback (Woods, 2010). As discussed in an Agile and Lean Q&A sessions at ustwo, Carl a strategist criticises lean processes as being suitable for “life and death type products” that require more rigorous iterative testing (Edwards, 2014), whereas an Agile approach shares methods with engineering resulting in “increasing quality and stability” of the output (Woods, 2010). For me, both are tools and mindsets. Both work well depending on the project context and aims, but like every tool they should be used appropriately. According to Abi Fichtner, a good Agile team picks and chooses the management and technical practices that work best for them (Fichtner, 2013). This thought is shared by Rally Software, a global provider of software solutions, and is reflected in their findings. Ryan Martens, CTO of Rally Software saw their customer’s products get to market 50% faster when they employ a hybrid of Lean and Agile development methods (Woods, 2010).
Managing Projects - A Critical Reflection October 2015
Page 19
PROJECT MANAGEMENT IN PRACTICE An overview of the different frameworks of Project Management and their practical uses.
ISSUES ENCOUNTERED DURING TEAM PROJECTS CONFLICT As part of the my time in Hyper, differences of opinions or conflicts were frequent within teams. Many reasons attributed to these tensions –we are a culturally diverse group, projects were quickly paced, the uncertainty around successfully “cracking briefs”, and even the vulnerability in the act of creating that leads people to be more sensitive than they might normally be. Conflict in creative environments is inevitable but this is not necessarily a bad thing: differences in opinion feed debates, sparking novel concepts and creative problem-solving (Flanagan and Runde, 2007). The key to approaching conflict is “how to get the best from these inevitable differences and disagreements...while minimising the harm (Flanagan and Runde, 2007). My experience was the larger the team, the higher the chance of conflict. I saw this in particular during the Experience Design Exploration module. We were a team of seven working on a brief to envision a transportation hub of the future. As part of this team, I saw conflict arise as a result of problems communicating and feeling “heard”, reactions to perceived disengagement of others, and creative differences on what “look” the project should take. In 1965, Bruce Tuckman defined the process of team development as forming, storming, norming and performing developed by Tuckman (Wei et al, 2013). The storming stage is the conflict stage and ideally teams should move out of it as quickly as possible. Conflicts during this stage are mostly attributable to the unbalancing of personality caused by team formation (Wei et al, 2013). We worked incredibly hard to improve our culture, drawing frequently from all the tools and methodologies taught to us in Hyper Island. We had reflection sessions every second day, with additional ad-hoc
Managing Projects - A Critical Reflection October 2015
Page 22
feedback sessions when the team felt they were needed, for example when people appeared to be disengaged. We used our emotional intelligence and made steps towards creating a climate of trust (Flanagan and Runde, 2007). We discussed and fed back on helpful and hindering, we used tools such as active listening and the Johari window (Luft and Ingham, 1965) to help be more aware of ourselves and others, and to aid our team development. As a team we never reached the “Performing” stage, but we did start to make decisions faster, coming to agreement more quickly, ultimately completing and delivering the project, and gaining insights into how best to optimise our future team.
TIME MANAGEMENT Time management was also a frequent issue in the teams I have worked. This issue manifested itself in two ways: handling and completing tasks, and also timekeeping and punctuality. Both of these problems had their own effects on the team had to be dealt with in seperate ways. For me timekeeping is a question of professionalism and should be taken seriously. There was issues of poor time keeping in my first team. The issue hindered our workflow as we would have to wait until all team members were present, often between 30-45 minutes late each day. With project times being short in Hyper this was 3045 minutes of work time we were losing each day. As a team we discussed the timekeeping issues with the person involved, as when this person was late the team felt frustrated and not respected. The feedback was taken on board and the situation improved. Following on from that, in other teams I made it part of the discussion when creating our team culture, to establish what people’s expectations are when it comes to punctuality and attendance. As a team we would agree on what the protocol would be. For example, in my last team, we had a penalty for lateness. If you were over 15
Experience Design Exploration - DXD Crew 1 October 2015
Page 23
minutes late you had to bring coffee. It’s a simple hack but it worked, and we only needed to get coffee once. From the perspective of time management in projects, keeping to schedule and meeting deadlines were common issues. We would often run short of time at the end of projects or just not getting through enough work in a day. As a solution to this we had schedules to keep us on track. Originally, these were written down on paper, in time we moved to post-it notes to allow more flexibility. These schedules could be constantly moved and adjusted to delays. We also used the board to overview the project and prioritise tasks. As part of my last team we worked in two-day sprints. We were very strict on ourselves if it was not done in this time, then it would be left until the next sprint. These “intermittent deadlines” (Pope-Ruark 2014) worked for us and allowed us to get through four rounds of iterative prototyping and feedback.
Managing Projects - A Critical Reflection October 2015
Page 24
Post-it Note Scheduling proved to be a more adaptable and flexible approach to time management.
PRACTICAL SKILLS NEEDED FOR MANAGING PROJECTS EFFECTIVELY As projects become increasingly complex, the list of required skills, tools, and knowledge needed to navigate the terrain grows (Klein et al, 2014). Galvin et al, lists a range of requirements for a good project manager; from strong technical background, to hard-nosed leader, mature individual, someone on good terms with both the teams and management, a person who can keep the team happy and a “closer” (Galvin et al, 2014). As the tech industry searches for T-shaped people, M-shaped people, and unicorns, project management seeks similar polymaths. In order to discuss this very long of practical skills, it is probably best to divide them into hard and soft skills. The hard skills take the form of organising and progressing projects, dealing with the necessary paperwork and scheduling, as well as budgets and estimates, ethics and guidelines (Holland, 2015). The project manager needs to maintain quality and ensure tasks are completed on schedule. They also need to have technical knowledge of the project, not expert knowledge but an understanding of the processes (Holland, 2015). But in my mind, it is through the soft skills of leadership and communication, that a project manager can distinguish themselves, and become a project leader (Galvin et al, 2014). Project leadership requires the use of multiple techniques and the ability to adapt to any type of situation (PMI, 2013). A good project leader can identify the value adding activities, energising others to follow the process and to take responsibility for delivering the tasks required, whatever the challenges (Holland, 2015). Pandya states a good project leader needs to project “positive values, highest levels of ethics, morality, ...and interpersonal skills” (Pandya, 2014, p. 40). Successful project managers leaders use their leadership, team building, communication, interpersonal, and motivational skills, to “create a culture where people are empowered and inspired by a common purpose” (DuBois et al, 2013).
Managing Projects - A Critical Reflection October 2015
Page 26
Through use of these skills, project’s stakeholders, clients, teams and management are more likely to feel a positive effect of a project. Projects also run smoother and positive results in less time. (DuBois, 2013). I think at times the lack of leadership did hinder our workflow within teams. The great thing about Hyper Island is its egalitarian nature, every person having equal say. But this has its downside. Team members were resistant to expressing points of view that were in contradiction with the team, so as to avoid conflict leading to a lack of challenging the work. We relied heavily on dotmocracy to make any decisions and it seemed more like stalemate than decision-making. Ultimately it seemed we wanted a leader with the “definitive final say.”
Managing Projects - A Critical Reflection October 2015
Page 27
Field research and ideation
Managing Projects - A Critical Reflection October 2015
In hingsight, appointing a Project Manager at tthe start of projects would have been beneficial, leading to more efficient time use and more definitive direction. Page 28
None of my teams in Hyper Island used a project manager and I feel this was a big mistake. We lacked leadership in the project, frequently over running our schedules and resulting in long hours in a bid to catch up. At times there was a lack of cohesion in design as ultimately no creative leadership had been appointed either. This lack of leadership affected our culture and lead to conflict as previously discussed. We did experiment with different approaches to roles and task across the different teams in Hyper Island. As part of the Transportation Hub brief, we decided on a “role” led approach to managing the project. I was in charge of art direction and suggested a style, the style was not agreed upon by everyone (in the team of seven). Amendments were made to the style and the group moved forward with that. The style was not adhered to across the project as nobody was ultimately
overseeing its implementation, nobody wanted to be “the leader”, this led to a lack of cohesion (and conflict as already mentioned) in the final design and animated film. Taking learnings from this we approached the Van’s brief with a “tasks over roles” approach. This seemed to show more promise but when it came to decision making this approach feel down. We struggled to come to agreement using tools like dotmocracy to make decisions but results were tied, and rounds of dotmocracy in a bid to have everyone agree, leading to stalemate agreements. Leadership would have benefited the group. Finally as part of our last project, the Playfully app, we agreed on a mixture of tasks and roles. We each worked through different tasks but each member had a role that they were to oversee like animation, visual design and interaction design. This worked the best as each member became a leader in their own field and the team respected the decisions made, and conflict was lessened.
Project leaders definitely play a key role in “building effective teams, creating frameworks to steer the team’s activities and motivating teams to stay focussed. (DuBois et al, 2013). This was often missing from our teams and would have greatly benefitted the projects.
Managing Projects - A Critical Reflection October 2015
Page 29
ETHICAL ISSUES IN TEAM AND PROJECT MANAGEMENT In Ireland the discussion of ethics, moral conduct and professionalism have been prevalent in recent years. These discussions have mostly been fuelled by the banking crisis, lapses of regulation of the building industry and our government’s reaction to these crises. But this spirit of introspection has spread into other industries like media and advertising, and designers have found themselves reflecting on current and previous practices. Within the field of project management, ethics and professionalism are considered “to relate to proper, acceptable conduct” (APM,
Managing Projects - A Critical Reflection October 2015
Page 30
2015) Professionalism is defined as demonstrating “awareness and application of competences and qualities, including knowledge, and appropriate skills” (APM, 2015). Ethical behaviour within the industry is seen as “maintaining the highest standards of integrity and professional conduct” and “encouraging others in the profession to act in an ethical and professional manner” through their own personal conduct (Ashrafi, 2013). Pandya states a good project leader needs to project “positive values, highest levels of ethics, morality, ...and interpersonal skills” (Pandya, 2014, p. 40). Project leaders also have to conduct themselves in a manner that is recognised as being “right” in the public’s interest (APM, 2015). As well as acting in professional and ethical way, project managers need to provide a physically and emotionally safe working environment for themselves and their team. They are obliged to respect “personal, ethnic and cultural differences” of stakeholders and team members (Ashrafi, 2013), sensitivity towards sexuality and religious beliefs should also be practiced. It is the responsibility too of the project managers to promote ethical practices in the workplace amongst themselves and their team (Ashrafi, 2013). Project managers also need to instil the utmost level of respect and professionalism, within their teams and projects. A project managers should not only be a strong leader, they need to be an exemplary one.
Experience Design Exploration - DXD Crew 1 October 2015
Page 31
CONCLUSION In a Harvard Business Review article Gary Klein, introduced the idea of a project premortem, as a tool for the successful management of projects. A premortem is a “hypothetical tool used to generate plausible reasons for a project’s failure” (Klein, 2008). The benefit of a premortem is team members can speak honestly about the weaknesses in a project in order to improve its chances of success (Klein, 2008). Research has found adopting this method of prospective hindsight (the founding principal of a premortem) increases a team’s ability “to identify reasons for future outcomes by 30%” (Mitchell et Al, 1989). The purpose of this essay is to reflect on the practical, professional, and research skills, I will need for my Industry Research Project. Seeing the value in this tool, I performed a premortem on my IRP. My main aim was to establish and address my own concerns early in the project. A “RESEARCH HOLE” I will adopt an agile approach to research, performing it in time-measured sprints. ustwo dedicates a day each week to researching project, preferring incremental research throughout the project, rather than focussing solely on research upfront. TIME MANAGEMENT ISSUES I worry as a result of poor time management, my writing will be left until the end of the project. I underestimate the time writing projects take me. I will work in a combination of iterative sprints and adopt a MLP approach for this. I will attempt to get the
basic written structure of my thesis in place early, working on the “minimum” basic version that says what I need to say, with the aim of growing it over the project time through writing, feedback and rewriting.
Experience Design Exploration - DXD Crew 1 October 2015
Page 33
A “BAD CULTURE” As I have found frequently in my research, culture is key to creating a fruitful work environment. Since leaving Hyper I have not created a healthy work culture for myself, working late and balancing personal commitments. I need to establish a better culture for myself. There are a number of self-management and communication software tools on offer to individuals. I am currently making use of the Slack communication tool with my former classmates, as well as Trello and Evernote, for organising and managing daily and weekly tasks. As part of our time in Hyper we were constantly in teams: working together, sharing knowledge, learnings and tasks. For my IRP I will in essence by my own team – researcher, writer, editor and interviewer. Since completing the taught part of the course, I have missed the day-to-day access to collective knowledge. Knowledge-sharing has been proven to be one the most important factors to support learning within organisations. (Almeida and Soares, 2014). These same learnings can benefit me as an “individual team”, in order to facilitate this knowledge sharing I will have regular check-ins with my Hyper team-mates (and of course my supervisor). I will also consider renting a desk in a coworking space to gain knowledge and exposure to professional practitioners. The success or failure of my IRP is hinged in my ability to manage it and myself. Through the combination of tools and techniques I have learnt in Hyper and through researching this essay, I hope to be better equipped to navigate the uncertain terrain of the IRP.
Managing Projects - A Critical Reflection October 2015
Page 34
Experience Design Exploration - DXD Crew 1 October 2015
Page 35
BIBLIOGRAPHY & REFERENCES
BIBLIOGRAPHY AND REFERENCES BOOKS Gothelf, J. (2013) Lean UX: Applying Lean Principles to Improve User Experience. Edited by Josh Seiden. 1st edn. United States: O’Reilly Media, Inc, USA. Maurya, A. (2012) Running Lean: Iterate from Plan A to a Plan That Works. 2nd edn. United States: O’Reilly Media, Inc, USA. Patton, J., Cooper, A. and Cagan, M. (2014) User Story Mapping: Building Better Products Using Agile Software Design. United States: O’Reilly Media, Inc, USA. Ries, E. (2011) The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Books on Tape. Sims, C., Johnson, H. L. and Pieron, I. (2012) Scrum: a breathtakingly brief and agile introduction. PLANETA. Sutherland, J. (2014) Scrum: The Art of Doing Twice the Work in Half the Time. United States: Crown Business.
JOURNALS Clarke, A. (1999) ‘A practical use of key success factors to improve the effectiveness of project management’, International Journal of Project Management, 17(3), pp. 139–145. doi: 10.1016/ s0263-7863(98)00031-3. Duggan, P. (2013) Going with the Flow – The Lean Approach to Successful Project Management. Available at: http://blog.backbase.com/2935/going-with-the-flow-the-lean-approach-tosuccessful-project-management/ (Accessed: 12 October 2015). Fortune, J., White, D., Jugdev, K. and Walker, D. (2011) ‘Looking again at current practice in project management’, International Journal of Managing Projects in Business, 4(4), pp. 553–572. doi: 10.1108/17538371111164010. Klein, G. (2008) ‘Performing a Project Premortem’, IEEE Engineering Management Review, 36(2), pp. 103–104. doi: 10.1109/emr.2008.4534313. Mitchell, D. J., Edward Russo, J. and Pennington, N. (1989) ‘Back to the future: Temporal perspective in the explanation of events’, Journal of Behavioral Decision Making, 2(1), pp. 25–38. doi: 10.1002/bdm.3960020103. Moe, N. B., Dingsøyr, T. and Dybå, T. (2010) ‘A teamwork model for understanding an agile team: A case study of a Scrum project’, Information and Software Technology, 52(5), pp. 480–491. doi: 10.1016/j.infsof.2009.11.004. Molhanec, M. (2007) ‘The Agile Methods - an Innovative Approach in the Project Management’, 2007 30th International Spring Seminar on Electronics Technology (ISSE), . doi: 10.1109/ isse.2007.4432868. Pope-Ruark, R. (2014) ‘Introducing Agile Project Management Strategies in Technical and Professional Communication Courses’, Journal of Business and Technical Communication, 29(1), pp. 112–133. doi: 10.1177/1050651914548456. Ratcliffe, L. and McNeill, M. (2011) Agile experience design: a digital designer’s guide to agile, Managing Projects - A Critical Reflection October 2015
Page 38
lean, and continuous. 1st edn. Berkeley, CA: New Riders Publishing. Svejvig, P. and Andersen, P. (2015) ‘Rethinking project management: A structured literature review with a critical look at the brave new world’, International Journal of Project Management, 33(2), pp. 278–290. doi: 10.1016/j. ijproman.2014.06.004. Wei, C.-C., Lai, M.-C. and Peng, L.-H. (2013) ‘Assignment of project members considering capability and personality balance’, Kybernetes, 42(7), pp. 1016– 1028. doi: 10.1108/k-10-2012-0096. Zarndt, F. (2011) ‘Project management 101’, OCLC Systems & Services: International digital library perspectives, 27(3), pp. 170–174. doi: 10.1108/10650751111164542.
WEBSITES, ARTICLES & IMAGES APM (2015) What is project management?. Available at: https://www.apm.org. uk/WhatIsPM (Accessed: 19 October 2015). Abi, F. (2013) Kanban is the New Scrum. Available at: http://www.hackerchick. com/2012/01/kanban-is-the-new-scrum.html (Accessed: 12 October 2015). Bowes, J. (2014) Agile vs Waterfall - Comparing project management methods. Available at: http://manifesto.co.uk/agile-vs-waterfall-comparing-projectmanagement-methodologies/ (Accessed: 12 October 2015). Clarke, A. (1999) ‘A practical use of key success factors to improve the effectiveness of project management’, International Journal of Project Management, 17(3), pp. 139–145. doi: 10.1016/s0263-7863(98)00031-3. DuBois, M., Hanlon, J., Koch, J., Nyatuga, B. and Kerr, N. (2013) ‘Leadership Styles of Effective Project Managers: Techniques and Traits to Lead High Performance Teams’, . Duggan, P. (2013) Going with the Flow – The Lean Approach to Successful Project Management. Available at: http://blog.backbase.com/2935/going-withthe-flow-the-lean-approach-to-successful-project-management/ (Accessed: 12 October 2015). Edwards, M. (2015) Ustwo Thinks 3 – Agile War Stories. Available at: https:// ustwo.com/blog/ustwo-thinks-3-agile-war-stories (Accessed: 12 October 2015). Gothelf, J. (2012) A Better Project Model than the ‘Waterfall’. Available at: https://hbr.org/2012/07/a-better-project-model-than-the-waterfall (Accessed: 19 October 2015). Holland, H. (2015) Project management role and duties. Available at: http:// www.successful-project-management.com/project-management-role.html (Accessed: 12 October 2015). Keller, H. (2014) The Agile Agency. Available at: http://www.edenspiekermann. com/blog/the-agile-agency (Accessed: 19 October 2015).
Managing Projects - A Critical Reflection October 2015
Page 39
Knight, J., Thomas, R. and Angus, B. (2013) The Dirty Little Secret of Project Management. Available at: https://hbr.org/2013/03/the-dirty-little-secret-of-pro (Accessed: 19 October 2015). Kodukula, S. (2013) The Differences: Lean Startup vs Agile Methodology. Available at: http://cabforward.com/the-differences-between-lean-startup-andagile-methodology/ (Accessed: 20 October 2015). Lee Whitaker, T. (2010) Differences between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!) | The Agilista PM. Available at: http://www.agilistapm.com/differences-between-waterfall-iterative-waterfallscrum-and-lean-software-development-in-pictures/ (Accessed: 12 October 2015). Luong, B. T. (2014) Forget MVP, Build a MLP (Minimum Lovable Product) Available at: https://medium.com/@brandontluong/forget-mvp-build-a-mlpminimum-lovable-product-efec985cb021#.nlq0x0s6e (Accessed: 12 October 2015). PMI (no date) What is Project Management? | Project Management Institute. Available at: http://www.pmi.org/About-Us/About-Us-What-is-ProjectManagement.aspx (Accessed: 19 October 2015). Polczyk, A. (2009) Scrum Available at: http://scrumpy.wikidot.com/scrum (Accessed: 12 October 2015). Principles behind the Agile Manifesto (no date) Available at: http:// agilemanifesto.org/principles.html (Accessed: 19 October 2015). Ratcliffe, L. and McNeill, M. (2011) Agile experience design: a digital designer’s guide to agile, lean, and continuous. 1st edn. Berkeley, CA: New Riders Publishing. Shalloway, A. (2009) Comparing Scrum to Lean - Not Quite Apples to Oranges. Available at: http://www.netobjectives.com/blogs/comparing-scrum-lean-notquite-apples-oranges (Accessed: 19 October 2015). Stulle, R. (2013) Agile – the best way we ever worked. Available at: http://www. edenspiekermann.com/blog/agile-the-best-way-we-ever-worked (Accessed: 19 October 2015). Tate, C. (2015) Assessment: What’s Your Personal Productivity Style?. Available at: https://hbr.org/2015/01/assessment-whats-your-personal-productivity-style (Accessed: 19 October 2015). Tom, G. (2013) Available at: http://www.slideshare.net/Tom- GrantForr/agile2013-presentation-tom-grant (Accessed: 12 October 2015). Woods, D. (2010) Why Lean And Agile Go Together. Available at: http://www. forbes.com/2010/01/11/software-lean-manufacturing-technology-cio-networkagile.html (Accessed: 12 October 2015).
Managing Projects - A Critical Reflection October 2015
Page 40
Betty the Cat, Lead Project Manager on this Essay.