Words: 4589
In, and working on, projects has been an Integrated part of mankind since the break of dawn. Man has always needed to fulfill unique purposes and deliver specific solutions to projects, whether that might be discovering new sources for collecting food or designing an opera house (Peacekeeper, 1995). “Projects” Is largely defined in the Project Management research as something unique, with a specific end date, several part-time goals and existing of several complex, internally co-dependent and susceptible activities (Backpacked, 1995).
Project Management as a field began arising around the sissies. It was founded on the idea of applying scientific methods to management, which is a discipline Frederick W. Taylor named scientific management in the beginning of the twentieth century during the industrialization. Taylor sought to improve organizational efficiency, and he did so by applying selectable methods to labor. His rational and linear approach led him to develop and experiment with such things as work standards, work motivation and maligning unnecessary movements for the workers (Hatch & Conclude, 2006,).
Taylor ideas of scientific management was adopted by Henry Ford, entrepreneur and developer of the first assembly lined manufactured car, the Ford T model (Greenbrier et. Al. , 2009, p. 374-375). Ford managed to cut production costs by adopting the principles of scientific management to almost a third of the original costs. During the industrialization, scientific management managed to cut production costs, which led to products being sold to a much lower price.
This affected the consumer demand to increase, and therefore the creation of new Jobs, which are a few of the reasons why scientific management was so understandable rising In popularity in that period of organizational development (Greenbrier et. Al. , 2009). The world Is now developing faster than ever, which creates continuous change In the organizational competition and environment. The life cycle of products are continually getting shorter, due to amongst others the rapid technological development, which has a great impact on consumer demands.
This causes more work to be project based instead of standardized work, which implicates that there are more uncertainties at risk, since there are fewer routines and repeatable work procedures (Harvard Business School Press, 2004). Therefore, Project management has evolved from the idea during the industrialization that there is such a thing as Best Practice, which is based a fixed linear standardized sequence of tasks, to accepting that in our time, there will always be a degree of uncertainty. This realization includes a much more contextual approach, where learning during the project Is an essential goal of the project Itself.
A Project Manager must accept, that one will never be able to beforehand determine exactly which uncertainties will arise, but one can hopefully determine which kind of uncertainties are at risk of affecting he project. This makes It possible for the Project Manager to plan which kind of management style would fit best with the determined kind of uncertainty, since the This paper will try to look upon the complexity and ultimate failure of a case project, and explain the need for alternative social approaches to management.
It will especially focus on the human side of project management, including such elements as culture, identity, group dynamics, previous team experiences and roles. The project, which this paper will examine, is the different stages and ultimate failure n the implementation of a new technology, in the largest Danish provider of television and broadband, DC. The technology in question is a decision determination program, called Decide, which the team was supposed to use in almost all instances.
During the project, the rules surrounding the use of the programmer, and the programmer itself, changed several times. The result was an extreme tension between the Project Manager and the team, the teams’ complete negligence of the orders given by the manager, and refusal of using the programmer, which led to the ultimate withdrawal of the programmer. I seek to analyses why the project failed by reviewing the different stages of the project and offer another viewpoint. Project Management Project management is defined as: “(… The allocation, tracing, and utilization of resources to achieve a particular objective within a specified period of time” (Harvard Business Essentials, 2004, p. X’). As mentioned before, a project is generally seen as a unique task in a specifically restrained time period. Within this period, there are certain defined performance goals that need to be achieved in order to evaluate the project at its termination. Furthermore, a project is generally seen trough systems theory, which demands that the project is seen as a tool to climb the ladder in the system itself.
It consists of three steps: plan, control and evaluation. The management of projects is defined as following “(… ) is the art of directing and coordinating human and material resources throughout the life of a project by using modern management techniques to achieve predetermined objectives of scope, cost, time, quality, and participant satisfaction. ” (Peacekeeper, 1995 p. 320) Peacekeeper (1995) finds that there are severe shortcomings in the field of project management, some of which has already been mentioned in the previous section.
He has defined three areas of weaknesses in the existing literature, which are identified as: “(1) PM is seen as a general theory and a theoretical field in its own right, (2) research on PM is not sufficiently empirical, and (3) projects are seen as tools’ ” (Peacekeeper, 1995, p. 319). Peacekeeper states that instead of describing projects with normative theories, based on ideal models of project planning and control, one should conduct and use research founded in the descriptive theories of human behavior and interaction. The support of descriptive instead of normative based both projects and the managing of them.
This is confirmed by his emphasis on being able to reflect with a decision maker in retrospective, and to understand why the decision maker made an ill Judgment. This is to create a sense-making process, so that one might learn from the mistake of others, instead of Just learning to identify which kind of error it was. “The main source of information about the course of action pursued within a project should be the individuals forming the project organization; action has to be understood as enactment of the subjective and inter- objective realities of individuals and groups of individuals” (Peacekeeper, 1995 p. 25). Instead of seeing the project in a systemic view as a tool, Peacekeeper suggests that one might see the project as a Temporary Organization. If adopting this perspective, one has to change focus from the three steps in the Tool metaphor of project management: Plan, control and evaluation, to the steps that the metaphor of the temporary organization addresses: Expectations, action and learning, with learning continuously circling back to expectations in a thought loop process, which again creates sense-making and learning (Peacekeeper, 1995).
It is my ambition to describe the chosen project case systematically, while debating which errors might have occurred with the system theory and best practice point of view, since they largely neglect the context and the human side of project management. Method The data for this project case has been collected via several different methods, with one common error denominator – that I was the only one collecting the data, and therefore everything is gathered and viewed from my perspective. Naturally, I tried to be as objective as possible, but one is always colored by own experiences, biases and framing (Barman & Bell, 2011).
Fortunately I had direct access to both the team and project manager in question, and could therefore conduct several types of interviews with both the project manager and team. In addition I was given access to the official data for Decide. I started by observing and emerge in the environment, and witnessed three meetings between the Project Manager and Team. I was a neutral observer, but my presence as a sudden strange intruder, must have had an effect on the general behavior and environment (Barman & Bell, 2011).
Afterwards I conducted two interviews with the project manager, and a focus group interview with members of the team. Half of them were selected due to my observations of their strong presence in the meetings, and I asked them to each invite a person that could many perspectives and viewpoints as possible, during my limited time with them. The data brought forward in this paper, is partly collected to answer similar research questions in another course, called (own translation from Danish) Methods of Interventions in Psychology and Leading of Change.
I do fell quite sure that the fact that I collected data for another paper simultaneously has not had an effect on the thoughts that this paper examines. This is because I needed the same type of data in both papers, with additional data in the other. So, even if having two similar perspectives had had a reasonable impact on the results of the data gathering process, it would have been in the other research paper. Decide The two biggest television and Internet organizations in Denmark started a public merging in the end of 2013.
The merging focused on the public perception of the two brands, and an internal structural streamlining. The two companies already had the same owners, and worked closely together, so the merging had minimal impact on he employees compared to other mergers in this size. During the focus group, one of the interviewed team members expressed that the only thing the merger had changed in their workday, was the new reception. The team was already used to frequent changes, and their daily leader – the project manager – had had previous success with getting the team to implement new projects.
The project manager gets his goals and orders from his superiors, which defines his area of project management as the role of the implementer (Harvard Business School Press, 2004). Therefore the project itself – implementing Decide – did not seem as a complex Job or the managers superiors, and he was only budgeted time to simply tell the team to use Decide, and a small amount of time during their weekly meetings to answer any questions there might be. His was given a success ratio, which started by being that in two months, which would be end of March 2014, 90 % of all the teams’ calls should feature the use of Decide.
This part-time goal was devalued several times, which created confusion structures for the project manager. He expressed concerns about his leaders laissez fairer changing of goals, since they weren’t the ones responsible for implementing Decide, and therefore not in touch with the actual use and debate about the programmer. The use of Decide has been constantly steady under 10 % in general for all the calls made, from February 2014 to the final termination of the programmer in May 2014. The project manager delivered another undesirable rapport to the sponsor in the beginning of May 2014, with the results for the teams using of Decide.
The sponsor announced that no more energy was to be wasted on the implementing of the program, shelved Decide and gave the project manager new goals. Concerns about the possible outcome of the project, since he beforehand had a munch that the team wouldn’t react well to the loss of autonomy that naturally would follow by using a decision determination programmer. His previous success stories had always had one common denominator – the team agreed on the rationality of the project. They didn’t necessarily have to like the different projects, but rational arguments had previous had a positive effect on them.
The project manager thinks that this is because all of the team members only work part time, and most members studied simultaneously at the university, where logic and rationalization is a cultural virtue. He therefore thought, that if only the team disliked the programmer, but could follow the rationale behind the need of it, and then it would be a success. The team consists of 21 people between the age of 20 to 34, in a divers range of sex, religion and origin. They work as a support unit, where they take calls from customers whom are in need of help with the organizations products.
The project manager addressed the need for Decide, by argument that they needed to have a more identical support-service, the new members of the team needed to have a faster and more stable support, and lastly some of the teams revises assignments were taken over to another department. All was to give the customers a faster, more identical, support. During the focus group interview, it became clear that the team unanimously see themselves as working in a service unit, where they have to solve a wide range of unique problems everyday.
The focus interview was conducted in April, where it wasn’t clear what the future of Decide would be. What was perfectly clear was that none of the members used Decide in general. Some of the focus group interviews stated, that it was an order they had Ben given, and therefore they used it moieties. When asked how frequent the vague ‘sometimes’ was, they said one out often times. The official data for Decide is that an average employee in the team uses the programmer 4%, which is quite afar from the first part time goal of 90 %, or the other part time goals for that matter.
When the project manager first described Decide to the team in January, they were initially neutral about the programmer, and would wait to pass Judgment upon it until they used it. The project manager explained that this was a normal reaction, since they implemented new programs every other month and therefore were used o this procedure, and had learned from experience not to fear new projects, but simply wait and pass Judgment upon it when using it. The focus group interview gave the members of the team an opportunity, to tell why they did not want to use Decide.
It was not, as the project manager suspected, a loss of autonomy that were a problem (although it might have been, if they actually used Decide which causes loss of autonomy). The team simply didn’t think the program worked. They experienced it as both extremely slow, and having a lot of errors. The inquiries, where they felt they needed a quicker and more similar support, which hey did not think it fulfilled. Instead they felt Decide was both demeaning to their support skills, and ended up with giving the customers a worse support than without it.
Essentially, they agreed with the theoretical rationality of the program, but did not think it accomplished any of it in practice. Furthermore, they believed there was a clash between the organizations values for the support department, being passionate, personalized and interested, and “reading a manual like a robot”. The team were invited to take personal time off, and report if they had any ideas that could improve Decide. Most of them did this in the beginning of the implementation in February 2014, but there were never any response to their ideas of development, or any progress in the programmer, which frustrated them a lot. I would like to note that several other teams also had to implement Decide, but since they are not a part of this research papers focus, I have chosen not to study their results. It could be interesting to examine and compare different teams success with Decide, so to see if any differences could be explained by underlying social and cultural differences in the teams Discussion Decide was launched extremely informal, and several of the team members expressed that they did not even knew they had to use it from January, or where to even find it.
This is already an indicator of lacking of essential information and objective from the very beginning. According to the Harvard Business Essentials (2004), it is extremely important to establish a common set of goals for the project, which must be fit with the organizations goals. When the teams working values are being passionate, personalized and interested, that conflicts directly with the use of a decision termination programmer, which is, pr. Benefiting, standardized.
When there is a direct conflict of the goals of the project and the organization, the project is highly likely to either fail and/or have negative consequences for the organization (Harvard Business School Press, 2004). A temporary organization has to be aware of the strategic agenda of the super-system in the company and be aligned with these (Peacekeeper, 1995). This might also be why the team does not seem to have any moral scruples about disobeying an order, because they feel that they are doing their job within the given values of the organization.
This is confirmed by their strong commitments to the service function of their Job – they don’t lack team commitment, its Just not aligned with the use of Decide and allocated elsewhere. The sponsor – whom in the case of the implementation of Decide is the project manager’s superior – should have accountability for the projects performance, provide the necessary resources and approve or reject the final output. A sponsor is supposed to promote project goals and support the innovation that follows (Harvard Business School Press, 2004).
The project manager has had ever-changing goals, even by the project sponsor, creating immense uncertainty for the manager. This weakened both his authority in front of the team and the stability of how they saw the programmer. The project manager is, as it often is in smaller projects, both manager and project team leader (Harvard Business School Press, 2004). As mentioned, there were only a time limited goal, and success percentage of calls where Decide was used that were planned before implementing the programmer.
The time limited goal and the success ratio of 90% of all calls should be answered with Decide is utterly overestimated. A Work Breakdown Structure (WEBS) might have brought a more realistic estimate forward, with fewer fiasco to follow up upon due too lack of communication. WEBS is a powerful tool for anyone working with projects, since it breaks the project down to manageable size bits and parts, and reveals the real scope of work. When this has Ben done, the responsibility can be divided, work assigned and in which order they should be conducted (Harvard Business School Press, 2004).
None of the team members had any responsibility for the implementation of Decide, which may also be one of the factors for the ultimate trihedral of the programmer. There were no pride in getting Decide to work, no accountability if they did not use Decide, way to much uncertainty since the rules surrounding the program changed every other week, general dissatisfaction with the program, and no response when the team tried to give constructive criticism.
If the team is correct, and Decide is indeed very slow and full of errors, then a WEBS might have showed that it wasn’t ready to be implemented yet, and a lot of wasted resources could have been spared. WEBS is promoted in both of the mentioned reject management metaphors, tool and temporary organization, but if one includes the human aspect of project management, a whole new resource comes to light. The fact that the team used their own time, to give constructive criticism shows a picture of really dedicated employees, whom are in sync with the organization and aligned with the culture.
Their contributions might be worthy of listening to, acknowledge or even implement. The failure of allocating responsibility to the team could be solved with the help of Rogers & Blesses (2006) RAPID model, which helps managers “clarify decision accountability’ (Rogers & Blenny, 2006, p. 1). They state, that in order to both make more efficient and lasting decisions, one should clarify peoples roles and give them personal responsibility and defined assignments.
The different roles in RAPID are as following: Recommend: People in this group confer with the Xi’s in order to make recommendations to the As. Agree: These people have to reach consensus regarding a recommendation before it can be decided upon. Input: The Xi’s provide input in order for Or’s to make the best possible recommendations and for As and DSL to reach the right decision for the team. Decide: This person has the final say in decisions and is responsible for the outcome of the decision.
Perform: These are the people who will carry out the decision in the end. 0 When defining roles in the RAPID the project manager, project sponsor and the team. The team both wishes, and is being encouraged by the project manager, to come forward with their inputs while performing. The team thinks that the project manager is the Deciding part, while in reality he can also only bring forward his input. It is the project sponsor whom has the final say, but he has allocated a lot of the responsibility, but not authority of sections, to the project manager.
A clarification, or even better, a negotiation, about the roles which the team, manager and sponsor see themselves fulfilling would create increased commitment to the project, and the teams methods of improvement might be implemented so a better more innovative program could be developed (Harvard Business School Press, 2004). If we looked at the project as a tool, none of these problems would have risen. The project manager would tell the team to use Decide, and they would Just do it.
If the program really slowed the team down and were instrumental in making the support rose, quantitative results such as time pr. Call would show this, and the sponsor would adjust. This may quite possible be what the project sponsor expected, which indicates that he has a Best Fit practice style of management, and it would be the perfect example of Scientific Management and seeing the project as a tool. But even Henry Ford had to accept that “(… ) every time I ask for a pair of hands, they come with a brain attached”.
Peacekeeper (1995) and his focus on the human side of project management gives a more detailed view of the situation “When projects are geared as tools, the various motives of the individuals in the project organization for participating (… ) are also neglected. Traditionally, individuals are not supposed to have motives when they Join the project organization; they are to be motivated by the project manager”0(Peacekeeper, 1995, p. 326) It is extremely important to note that each person has unique individual en specific agendas, and is an integrated part of the organizational culture.
The team has a strong support culture, and would go to great lengths to ensure that their customers’ problems are being handled in a specialized way. Neither the manager nor the sponsor have succeeded in convincing the team that their culture can support the use of Decide, and again, because a decision determination program by nature goes against the teams official values in the organization; being passionate, personalized and interested, it might be entirely impossible to have the two cultures be combined.
If the manager and the sponsor had seen the project as a temporary organization, they would have known the importance of building a new culture for that specific project as a sub system. The manager could have argued, that the team was a elected test team, and that they therefore should act not like themselves, but like a standard employee. By doing so, the manager could make the team shift identity and separate their existing culture from the temporary; there may likely have been a much larger percentage of calls taken with the use of Decide.
It is important not to neglect the fact that each person has an individual and specific agenda, and is also a part of a greater organizational culture. It is essential for the project team to create a new culture or a common understanding when entering a sub-system as a temporary organization (Peacekeeper, 1995). Evaluation have any budget to grant bonuses for using the program, he had no means to reprimand the team for not using it, and he couldn’t convince them of any positive effects of Decide. The sponsor chose not to waste anymore of the project manager’s resources, so the sponsor terminated the program.
The evaluation was simply, that the manager failed in implementing the program. If both the sponsor and manager chose to see the program as a temporary organization, they would have been forced to learn from the fiasco instead of Just defining it as a fiasco. With the temporary organization in mind, it would have required them to make a continuously developing thought loop process, and thought a sense making process define where they might act differently in future projects. Instead, history could repeat itself and more resources possibly wasted in the future, with the exact same evaluation to follow.
Conclusion This paper has identified several shortcomings in the project of implementing Decide. The project manager failed to make adequate preparations for the implementation of Decide. This resulted in some of the team members not even knowing about Decide before a couple of weeks in the implementation process. The success rate given by the sponsor was not all adequate, and showed signs of the scientific management method, which neither is adequate for an ever-changing technological support organization in our time. Seeing the project as a tool did not work in this project case, since it neglects the human facets of projects.
This is not saying that the Tool Metaphor wont ever work, but when human aspects such as a strong culture and identity directly clashes with the project, it might be more useful to see the project as a temporary organization. If the tool metaphor of the project were fulfilled, there would both be a bonus for using Decide, and an adequate punishment for not doing so. The project itself was not aligned with the organizations values, and there were no attempts of creating a new culture in the temporary organization that could support the project.
The responsibility for the implementation was the managers, but he wasn’t given the proper tools to accomplish the project by the sponsor. The team did not have any accountability towards the success of Decide, and when combined with the clash in the values and densities it is natural they did not adopt it. This also supports that there were an unspoken disagreement between the project manager, project sponsor and the team about their roles and responsibility, which a RAPID schema would define.
A learning process never started, and no one listened to the teams concerns and suggestions for a better program, which might both have included the team, updated the program to a better version, and created a fellowship of responsibility towards the program from all parts involved. I would recommend appreciating the team for their dedication to their values, instead of treating a strong supportive culture as a problem for the managers. It is a valuable asset, which can be used to test new projects and save resources.