PROJECT MANAGEMENT INPRACTICE: A REFLECTIVE ESSAY AbstractIn this reflective essay,the topic of Project Management is explored, relating it to stakeholder management in the context of personal teamwork experiences gained from the Practice Track projects. A deep reflection is done on both projects utilizing the Gibbs’ Reflective Cycle model.The main purpose of this essay is to reflect upon the experiences with a critical eye, identifying what went well and points of improvement. To evaluate the experience further, a literature review and discussion of academic theories arisesfrom comparing them with personal observations made during the projects. The main findings are that contingency plans must be set in place when planning a project. Also, trustamong team members yields more efficient work and positive team spirit. Lastly, distributing tasks equitably is keyto empowering team members and distribute responsibilities..To finalize the Action Project, we were asked to present the process via a narrated presentation. The third component of the practice track is areflective essay, which must analyze a topic in light of the experiences I had as an individual and within the team. In this reflective essay I will be exploring the topic of project management in relation to my own experiences working in a team. Afterhaving compiled a literature review on what project management is and the different theories surroundingit, an evaluation will take place. I will be comparing the literature to my experience, observing if my experiences can be a case of the practice of these theories or whether they are far away from the set theories and strategies.Lastly, I will reflect on the experiences and learnings from these projects using the Gibbs Reflective Cycle.2.Literature ReviewThe topic chosen is Project Management, as this is at the core of our teamwork, and defined how we managed the team, planned activities and executed them effectively.Firstly, we must define what project management is. A project is simply defined as a task that has a beginning and an end. However,this definition is too broad, and many institutions have tweaked this definition into a more concrete one. The Association for Project Management (2019) defines projects as “unique, transient processesundertaken to achieve a desired outcome”.And then it defines project management as the application of procedures, knowledge, skills and experience to achieve the project objectives.The British Standard 6079 4 (NBS, 2019) defines a project as: “A unique set of coordinated activities, with definite starting and finishing points, undertaken by an individual or organization to meet specific performance objectives within a defined schedule, cost and performance parameters”. This definition goes further to describethe time element of the projects, as well as who carries them out, with specific objectives and then the measures such as cost and performance.Freeman (1984) first defined a stakeholder as “any group or individual who can affect or is affected by the firm’s objectives”. The most recent and complete definition is by the Project Management Institute:“Stakeholders can be an individual, group or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity or outcome of the project” (PMI, 2013)In the book by Worsley(2017), she discusses that if a project is defined primarily by deliverables, stakeholders aren’t the main priority and that in turn, if a project’s nature revolves around stakeholders then stakeholder management is the uppermost priority. Nonetheless, most of the projects find themselves in betweenthese extremes, and as such,
2acquiring a stakeholder management strategy is key when it comes to planning projects. She also poses that stakeholder management doesn’t comprise a set of steps, but rather it is a viewpoint to be used when directing the project(Worsley, 2017).What Maylor(2010), discusses in hisbook is that the measures used to quantify the success of a project, should not be limited to cost and performance. Also, he challenges the metrics used, as “performance” can be interpreted in many ways. As so, he proposes that measurementshould betakenfrom doing astakeholder analysis. Identifying who should be monitored, who should be kept informed,stakeholders who should be kept satisfied and finally the stakeholders which should be managed closely(See Figure 1).The objectives of the project should be in line with what the high interest and high power stakeholders expect, but also keeping into consideration other moderate priority stakeholders, who should also be satisfied to some degree. For example, measuring customer satisfaction would be appropriate when the customers are the highest priority stakeholder.Figure1: Stakeholder Power-Interest map.In the blog by Ben Aston (2017), nineof the most common project management strategies are explained. Among them, popular strategies such as Scrum, Kanban, Waterfall and PRINCE2. While most of them focus on planning all activities at the beginning, executing tasks stage by stage, the Agile strategy is more adaptable, as planning is an on-going task. The Agile method is characterised by having individuals and interactions take priority over processes and tools (Aston, 2017). Tasks are conceived, executed and adapted as change happens, ratherthan having a pre-planned process (Aston, 2017). It also doesn’t assumethat possible setbacks are predictable like other strategies do. This can be beneficial for teams who are unsure of how some parameters might work out. However,this method can be detrimental to a team thatneeds much more structure and a clearer picture of how the project is going to be carried out.If that’s the case, a Waterfall strategy would fit in best(Aston, 2017).Ultimately, having an Agile strategy allows teams to respond to unpredictability through incremental, iterative work processes (Aston, 2017).
3The benefits of the Agile method are evident when it comes to customer satisfaction. The traditional methods focus on developing requirements and specifications at the planning stage of the project which limits changes to these specifications during the execution phase. On the contrary, the Agile methodcan adapt the requirements during the whole process, as it recognises that satisfying customers is more important than managing the scope of the project(Masood, 2017).Another benefit of the Agile method, where changes are easily made,is that it avoids costly rework, due to the iterative nature of this method(Masood, 2017).One of the challenges found in using the Agile method is the measure of quality, since the specifications aren’t predetermined in advancethere is no benchmark to verify the quality. (Kurup & Sidhardhan, 2015)The biggest hurdle to overcome when it comes to the Agile method is knowledge management. Traditionally, documentation is kept to maintain knowledge within the organization. However, in the Agile method, teams can make their own rules and structures during the project, which are not recorded and only live in the minds of the team members. This tacit knowledgecannot be easily transferred within the organization(Masood, 2017). Although this seems to be the case, in the study by Stadler and Fullagar (2016) it was found that effective collaboration among team members is fundamentalfor the success of theorganizationor project. To achieve this, trust relationships are key when it comes to sharing information, as more elaborate questions can be asked without the fear of being judged. Thus, knowledge can effectively be transferred and directly affect the success of the project, as posited by Stadler and Fullagar (2016).This,however,is not applicable invery short-term and intense work environments, as trust relationships cannot be formed as quickly(Stadler and Fullagar, 2016). Also, sharing everything with everyone might not lead to the best results, as information overload can happen (Stadler and Fullagar, 2016).According to Stare (2014), there are substantial barriers in adopting the Agile method outside of the IT and engineering industries. (Stare, 2014).He justifies this by claiming that the Agile method emanated from the software development industry, and it couldn’t work outside this or related industries. Also, he found that up to 2009, of thirty-three articles only three did not discuss IT projects.Conversely, Le May (2018) discusses in the book “Agile for Everybody” that the Agile method can be used in many different industries.In his research interviewing professionals from diverse industries and different levels of experience, he was able to draft several real-life examples, of how people across functions and industries have used Agile methods to meet the requirements of their organizations, customers and team membersLe May (2018)Traditionally, the critical path method (CPM) is used to guide the project manager as to the consequent activity of a project. It presumes that activity durations are predetermined(Maddah, 2009).Similarly, the program evaluation and review technique (PERT) lists activities based on the type of work to be executed(Maddah, 2009).Shtub (1997) suggests breaking down the project into segments, fitting to managerial considerations, instead of the traditional ways of CPM and PERT methods, where activities
4are divided based on their type.This idea maintains that by separating based on managerial requirements, it gives more flexibility to the project team both at the planning and execution stages (Shtub, 1997).Another Project Management topic that aligns with the previous literature is that of Scope Management. In their book “Project Management Toolbox”, Martinelli and Milosevic (2016) clarify the concept of scope planningby emphasizing that it is,in fact,a collaborative process between the project manager and the stakeholders. This is because the goals set by stakeholdersoutlinethe project, and as such, the planning for it.Scope entails having clear guidelines and boundaries as to which activities are to be done. Combining scope management with budget management, schedule and risk planning will lead to a formation of a plan. Scope management continues throughout the project, as changes occur and boundaries are needed to not incur unnecessary tasks(Martinelli and Milosevic, 2016).They defend that change is inevitable when dealing with a project and that it can alter the course of a project. This means that scope management should account for this and evaluate whether the changes are needed and if they are, how can they best be applied(Martinelli and Milosevic, 2016). This ties in with the Agile methodology, where changes are an essential part of the process, as they shape how the on-going planning is carried out. To define scope, project managers can use the work breakdown structure (WBS)(See Figure 2), where all elements and sub-elementsof a projectinteract with each other (Khan, 2006). Each stage requires reporting, which is beneficial to the overall project. Yet, having too many elements can consume precious resources when it comes to reporting too many details. For this, a healthy balance must be found where the correct numberof elements are selected, to avoid overworking while maintaining control(Khan, 2006).Figure2:Example of Work Breakdown Structure.
53.EvaluationFollowing the definition previously given by theProject Management Institute (2013),I see how the University is a stakeholder, as it affects how we will be evaluated. Herman Millerfrom the company project is a stakeholder as it receives the deliverables of the project:a strategy proposal.And lastly, SARSASfrom the action project benefitted directly from the project activities of fund and awareness-raising.In the book by Worsley (2017), she proposes that stakeholder management is a viewpoint to be used when directing the project. We found this to be true in our experience. I observed that we didn’t follow certain premeditated steps when it came to stakeholder management and rather used it as a mindset with which to approach the project.In Maylor’s (2010) book, he argues that choosing the measures of success should be based on the stakeholder analysis. In our case, we had several stakeholders. The company contact from Herman Millerwould expect a specific strategy to solve the issue as well as checking if social media channels are effectively incorporated. For the same project, the University’s expectations were regarding the use of academic models to support the findings, critical and creative thinking and the presentation itself. The charity for the Action Project had as a measure of success the amount of funds raised. No specific objective was given, but we made our own goal and surpassed it. For the same project, the University is again a stakeholder who expects a justified academic approach and a clear timeline presentation. These are very different goals to achieve, and as a team, we had to make sure to satisfy all stakeholders in this case, by looking back at these measures. I completely agree with what Maylor theorizes, as paying attention to what measures matter to the stakeholders, can help formulate and reach goals easier. As so, our measures of success were designed to satisfy all stakeholders.Based on the nineproject management strategies from the Aston (2017) blog, we identified that our project was not highly complex, we familiarized ourselves with the clients, accounted for the available resources and identified the constraints (time constraints as well as budget constraints). We took each project’s planning separately, starting with the Company Project. We didn’t have an initial plan of how we were going to work, but at each meeting,we decided what needed to be done and assigned tasks to be completed by the next meeting. We all knew more or less what needed to be done, as we are all on the same page. I felt this was the right way for us to work, as too much structure might have been overwhelming, and we would end up changing the plan halfway through anyway, because of some setbacks. We also discussed as a team how we wanted to plan these projects and we decided to plan on the go, which if compared to the strategies outlined by Aston (2017), we followed an Agile methodology.As Masood (2017) outlined, there are great benefits as well as certain challenges when it comes to the Agile project management methods. Satisfying customers is more important than focusing on the details of the planning process, and that is something we followed. We would ask for feedback from our company contact at Herman Millerand requirements would change slightly after every meeting, as the question became more and more specific. We also ended up changingthe plan for the fundraising activity, to be able to fulfil SARSAS’goal of
6raising as many funds as possible. The changes were made organically, as we pursued the client satisfaction.The next benefit Masood (2017) lists is that the Agile method helps avoid rework. However, this did not apply to ourexperience, as we had to scrap certain research and findings once the requirements were tweaked after each meeting with the company contact. Conversely, I do agree with the challenge identified in Kurup & Sidhardhan’s (2015)paper, where theysay that measuring the qualityof a projectcan be challenging. This proved to be true,as objectives for the project would slightly change after every meeting, and the measures of quality would change with them.Masood(2017)finds another challenge in the Agile method, which is that of knowledge being lost since it is tacit knowledge and can’t be transferred easily. I did not encounter this challenge, as I felt that as a team,we created trust relationships with eachother, which facilitated the transfer of information. This observation is supported by Stadler and Fullagar’s (2016) research, where they maintain that effective collaboration among team members through trust relationships is fundamental for the success of the project. One caveat posed by Stadler and Fullagar (2016) is the case of information overload. This didn’t happen during our projects, as we made sure to delegate tasks and only share information during meetings, where everyone was present, therefore avoidinghaving to repeat information. The Agile method as a concept emerged from the software development industry. Stare (2014) remarks that the Agile method isn’t widely used outside the IT industries, and that is because it would simply not apply. From my experience, I’d have to disagree. We utilized the Agile method during the project for the marketing of Herman Miller’s offerings. Moreover,it is a fact that Agile has been used in other industries, even if it hadn’t been identified as such at the time of the project execution.This is explainedin the book “Agile for Everybody” by Le May(2018), wherehe collected many examples of the Agile method being used in different industries and functions,and bases his book’s teachings on these examples. As so, I agree with his judgement that Agile is in fact for everybody.Shtub (1997), recommends breaking down a project into segments, as these would fit best with managerial considerations, rather than by type as would be done in CPM and PERT methods.This methodology fits well with how we planned our projects. We divided tasks in chronological order (for example April is fortheplanning of operations, May is for booking locations and reserving materials) and then divided by segment, for example, the action project was divided into the “Green Park” event and the “Pigeon Park” event.When it came to scope management, we found ourselves having to collaborate with the company contact to shape our goals even further. This led to a collaborative process, which is the premise of the book “Project Management Toolbox” by Martinelli and Milosevic (2016). They defend that change is inevitable when dealing with a project, and that it can alter the course of a project. We encountered our first change with the action project when the proposal was deemed not adequate, as our planned activities were too costly and we didn’t meet the requirements of hiring a certified instructor for our self-defenseclasses. We had to
7steer the project in another direction, and because our scope management was flexible and our methodology Agile, we were able to quickly change plans and pursue another project.We used a work breakdown structure (WBS) as suggested in Khan’s (2006) paper. This permittedus to define scope and map out all the elements for our action project. He recommends reportingafter each stage, but not to over-report. We,however,didn’t report the activities as such.What we did was to take notes in our own reflective diaries, and then compile the facts and reflections after all the activities were completedto createthe narrated presentation. Figure3: Work breakdown structure used for the Action project.4.ReflectionFor this reflection, I will be following the renowned GibbsReflective Cycle.This method helps to examine experiences, evaluate them and find points of improvement. Since it is a cycle, it can be used for repeated experiences (University of Edinburgh, 2019)If a reflection was done and acted upon, later it can be reviewed once again, and new reflections and improvements can be found.To reflect upon the activities of the Practice track, I will be separating the Reflections into two sections: The Company Project and The Action Project.To follow Gibbs’ Reflective Cycle in my reflection, I will be explaining each situation following these 6 stages:1.Description of the experience2.Feelings about the experience3.Evaluation of the experience4.Analysis to make sense of the situation5.Conclusion of learning points 6.Action plan on future improvements
8Figure 4: Gibbs Reflective CycleSchön (1991)distinguishes between reflection-on-action and reflection-in-action. Reflection-in-action is concerned withdrawingon tacit knowledge to reflect on behaviour as it happens(Schön, 1991).Conversely, reflection-on-action ensuesafter the activity has taken place. In this reflective essay,I will be applying this method, as I’m reflecting after theprojects are over,torevisit and evaluate eachsituation andtakeaway lessons for the future.4.1. Reflectionon Company ProjectFor our company project, we were assigned Herman Miller, the office furniture designer and manufacturer. We had an initial meeting with the company contact at the University, where she presented the challenge to us. The brief can be summarized as follows:“Increase awareness of the Herman Millercompany for University purchase decision-makers in the UK and the region of Europe”.This was quite a broad brief, so we decided to meet as a team the day afterthe presentation. This was a good move on our side, as we avoided unnecessary questions and rather were able to ask purposeful questions after taking the time to think the brief through.We decided to conductmarket research, both market environmentandprimary research. Internal researchwas also done to learn more about how Herman Millerworks, what they are currently doing and identify points of improvement.We found that there was no social media strategy set out for university clients, and we made it our goal to create one that could be easily implemented by Herman Miller.I feel that taking the time to research the market and the company was crucial in the success of our recommendations, and I’m glad we took the time to do so.When it comes to content, we all worked on the poster equally, although we allocated certain sections to certain team members. We found this to be easier, as we could always refer back to the person ‘in charge’ if we had a specific question regarding one of the sections. I liked this way of working, as we were all responsible for a certain segment but in
9the end,we were all aware it is a team effort and the deliverables are everyone’s responsibility. This method could be risky, as we could have distanced ourselves too much from other segments, but since we worked together and always kept everyone informed, it worked out perfectly for us.I feel that everyone contributed equally, although some team members did take on more responsibility. At the end of every meeting,we would come up with tasks to be completed by the next meeting. Tasks were allocated on a first come first serve basis, meaning that if I really wanted to, for example, research the LinkedIn pages, then I would just say sobefore anyone else could claim it. Inretrospect, this probably wasn’t the best method to follow, as quieter team members didn’t get their say until after most of the tasks had been “taken”.Even if the tasks were allocated in this way, I do feel that we were fair, as each of us knew our strengths and the strengths of our team members, the more we got to know each other. Eventually,the allocating process changed. We would all first ask who believed to be the best fit for the task, and a negotiation of sorts opened up, which allowed for more equitable distribution of tasks. I realised this was an even better method, and we proceeded with it.When it came to the presentation, we again divided the segments among us, based on who was the ‘head’ of each section. We made sure there was continuity in our speech and rehearsed the presentation several times. After each rehearsal, we would give each other feedback, as to what we could have done betterandbody language suggestions.I’m convinced this was very helpful for everyone, as we enriched our presentation skills. During the first presentation, everyone was eloquent and confidently delivered the content. I feel that this gave us a boost in confidence, which was very beneficial when later presenting to the company, as we were more relaxed when delivering the presentation.The learnings I’d keep for the future if I was to work in a similar environment, would be to make sure to take our time to ask the right questions, by doing a good amount of research. Also, distributing responsibilitiesamong team members takes off the pressure and empowers all the team members.What I’d change and implement in the future, would be to ensure that tasks are allocated equitably among the members, based on their experience and interests, through a reasoned conversation.Overall, I feel that by supporting each other, learning to listen to each other and compromising where needed, we created a positive team environment thatled us to deliver quality content through a gracefulpresentation.