User:MSB/IMB-EU-2013/PS2-P2

This Wiki-page is a group term paper and result of an MBA module called Problem Solving 2.0. The authors are Anne Fiedler, Julia Gebert, Ruslan Vakilov and Svetlana Gaska.

= Introduction =

Agile project management (APM) as a way and philosophy of working and scrum, a more strictly defined working model, have been buzz words for the last couple of years. Having emerged as state of the art project management tools from the highly dynamic IT sector, they are increasingly applied in workplaces. However, the question that emerges from watching this trend is: What are the strengths and the pitfalls of agile project management and scrum? And are those methods or working styles transferable to non-IT areas, have other sectors adopted them meanwhile?

In order to answer those questions this study aims to shed light on the functional advantages of agile project management within companies and industries of different structures and sizes. In a world that is increasingly growing together beyond geographical and cultural boundaries, it is highly relevant to not only look at the mere processes but also at the people who are implementing them. The cognitive interest is here to see, how IT-dependent APM is and where and how it is applied in the IT sector as opposed to the non-IT sector. In a second step it would be interesting to find out what the reasons are to either apply it or not and whether APM is generally recommendable or rather for projects with a certain scope and length.

Firstly, a theoretical explanation of what exactly differentiates APM to other project management methods will be made. Here APM will be contrasted to the waterfall approach and two hybrid methods will be introduced that bear elements from both of the before mentioned.

Secondly, two case studies from the United Kingdom will be presented in order to understand better what determines success or failure of APM within a company or organization.

Thirdly, following the theoretical analysis and the case studies we will look into non-IT related but customer-focussed industries that and if APM has spread there, has been disregarded or if it might be recommendable.

Finally, we will use this term paper creation process as a self-experiment to evaluate whether APM was benefitial to write a group term paper, and assess if APM could also be applied in an academic environment more often.

In addition to the case studies and best practice examples integrated here, expert interviews have been accomplished to gain more insights in the "real" applicability of APM nowadays.

=Project Management Methodologies=

Waterfall Model
One of the first structured process models of traditional project management is the waterfall model which will be explained in the following.


 * What is the waterfall model?

The origin of the waterfall project management approach was first presented by Winston Royce in 1970. In his disquisition on “MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS” he transferred his personal experiences in developing software packages for the spacecraft mission into a more general and abstract description that may apply to projects in the software industry. Although he did not use the term WATERFALL MODEL, by describing the steps of developing large software systems Royce initiated the theoretical rehabilitation of project management. Practically the waterfall approach was already exercised.

As already said, managing a project in a waterfall manner follows a certain sequential flow from top to bottom. In more detail, the Royce original model points out a number of steps starting with knowing and analyzing the system requirements followed by designing, testing and leading up to product release. The maintenance of the finished product should not be forgotten since it is one of the major cost drivers. ” The Picture on the right shows that carrying out tasks in a predetermined orderly sequence introduces the logical flow from top to bottom. Each task is expected to be finalized before the next one can start. In that way there is no forth and back within the project stages.


 * What is the added value of such a method?

Because each phase is documented accordingly, it can backtrack to the previous stage. In that way, the waterfall approach is one of the most systematic methodologies for project management. In the following table a collection of pros and cons about the waterfall model is assembled. This list needs to be seen as an evaluation which is not exhaustive. Different project types in varying industries might generate distinct advantages and disadvantages. Please keep that in mind.


 * How has the waterfall model evolved over time?

As project managers have seen the flaws and disadvantages of the approach for their specific applications in practice, a variety of modifications have been made. Each operator adapted the structure and system towards his/ her own requirements. And also theoretically a number of modified waterfall models were introduced.

In the following section, we will present two examples for adaptations of the original waterfall model towards agile: Neither fully agile, nor fully waterfall they are hybrids of both methods.

Hybrid Methods
After the waterfall model was introduced by Winston Royce in the 1970s, it has been applied by companies with various degrees of success. Towards the 1990s with the further development of technology, the number of IT companies increasingly grew. Being dissatisfied with the waterfall model some of them judged as inadequate for their purposes and decided to adapt it to their needs. One of these companies was Rational Rose which came up with the Rational Unified Process (RUP), that possessed the same features as waterfall like clear tasks following each other, but at the same time they added iterations inside - so these "blocks" were not dependant any more on each other but instead working parallelly.

Another example is the V-Modell, which was created by the German army and like RUP, was intended for use in a quite specific environment. While RUP was used for development processes in the Rational Rose company (later acquired by IBM) the last implementation of the V-Modell was applied during the development of the German e-government portal (XÖV, WibE, UfAB) for budget control, data communication, and so on.

Those two hybrid methods are exemplary, there are many more on the market, but they should serve as examples here to demonstrate the variety of project management methods once a clear cut model like waterfall is adapted to a specific environment in a corporation. Historically speaking, those methods heralded the transition period between waterfall and agile: Developers wanted more flexibility and were adapting existing methods, getting thereby increasingly closer to agility. In the following sections hybrid models will be examined in more detail. Description of these models was taken from their Wikipedia pages - RUP and V-Modell XT.

Rational Unified Process (RUP)
The process consists of the following details: Group of tasks creates a project. At the beginning, task are divided into 9 groups: RUP has four phases - inception, elaboration, construction, and transition in a quite linear fashion, at the same time being iterated. In the subsequent section those phrases will be explained in more detail.
 * Roles (who) – Here defined set of skills for people who will do some exact task.
 * Work Products (what) – This is a resulting object or a product after finishing a process.
 * Tasks (how) – It is a part of the work, that role should do to get some real result.
 * Six "engineering disciplines":
 * Business modelling - tasks that were responsible to create a business logic of a product
 * Requirements - input from the customer
 * Analysis and Design
 * Implementation
 * Test
 * Deployment - putting into production
 * Three supporting disciplines:
 * Configuration and change management - What tools to use, and how to efficiently manage them
 * Project Management
 * Environment


 * Inception

During this phase, planning and definition of the work and its impact is established and later it is being checked at hand of the following criteria:
 * Does everybody agree on cost/schedule?
 * Does everybody understand the process?
 * Were all risks, costs, schedules and priorities estimated well?
 * How thorough is the prototype made, and does it cover key features of the future product?
 * Creating a plan to compare factual and planned costs.

If the project does not pass this milestone, it can either be cancelled or repeated after being redesigned to better meet the criteria.


 * Elaboration

An analysis of the risks is made and the architecture of the process is created. At this point the project can still be redesigned or cancelled, afterwards it can become risky to make any changes to the design.


 * Construction Phase

At this phase coding is the main process. Main modules and systems are being created. In a big project, this part can be divided into smaller iterations in order to make things manageable. The result of this phase is the first release of the software.


 * Transition Phase

Here the final polishing starts, when the system moves from development stage to production, so the end-user can understand and already use it. Also it includes documentation preparation and user education. Additionally, quality checks take place in order to see if the product meets the requirement established during the inception phase. When all objectives are met, the development cycle stops.

V-Model XT
The V-Modell XT is mainly used in software development just like RUP. This model also tries to provide the maximum efficiency to the team and remove unneeded work. Furthermore, the model defines the communication process, to avoid possible misunderstandings between contractor and developer. The V-Model was first published in 1992 by the German army. Later two revisions were made, one called V-Model 97 and the other V-Modell XT, that happened in 2005. "XT" stands for "extreme tailoring" and introduces flexibility to the process. During the development of the this model, companies also took part in cooperation with the public sector.

Here is the list of the objectives that are supposed to be achieved during the process:
 * Project risk minimization: this model tries to improve transparency during the project, by specifying standards, and defining the internal processes and responsibilities. It helps to detect deviations from the plan in the early stages and thus reducing risk.
 * Improvement and quality guarantee: as long as a lot of processes and parts of the processes are standardized, it helps to get a complete product at a desired level of quality. Interim results can be checked at an early stage as well.
 * Reduction of total cost throughout the entire project and system life cycle: Transparency helps to easily calculate, estimate and control all efforts for development, production, operation and maintenance. All results are very clear and can be retraced. All this reduces dependency on the supplier and efforts for further activities and projects.
 * Improvement of communication among all stakeholders: All communication between stakeholders is standardized and documented, so any risks of misunderstanding is reduced.


 * Advantages

These are the advantages of V-Model:
 * The users of the V-Model participate in the development and maintenance of The V-Model. The change control board met at the time they need and processes all change requests received during system development and test.
 * The V-Model provides concrete assistance on how to implement an activity and its work steps, each activity scheme contains instructions, recommendations and detailed explanations of the activity.


 * Limits

The following aspects are not covered by the V-Model, they must be regulated in addition, or the V-Model must be adapted accordingly:
 * The process of placing contracts for services is not regulated.
 * The organization and execution of operation, maintenance, repair and disposal is not included in the model. However, planning and preparation of a concept for these tasks are regulated.
 * The V-Model is more applicable to the specific project, than in the whole organization.


 * Conclusions

As both described hybrid methods emerged from an in-house design process, they were developed according to specific interests and needs. Accordingly, they are still not as flexible and efficient as it would be desirable and have some disadvantages. However, this was already a big step towards more customer orientation and flexibility. It is interesting, how the mindset started to change in project management and how new methods emerging from this, such as the models themselves, are tangible proof of this development. It would still be a development of a couple of years, until the "Agile principles" were invented and enjoyed practical application and theoretical support. As a result a fast moving, highly adaptive model was developed: Agile Project Management. Covering a number of the previously introduced models' shortcomings, it generates new advantages but also disadvantages for the applying community which will be tackled in more detail in the following chapter.

Agile Project Management

 * What is agile project management?

Describing the essence of agile project management is particularly evident when contrasting it to the beforehand described “traditional method” of project management: The waterfall method. Agile project management (APM) tries to break with the routine of a stiff, chronological sequence of steps following each other within the course of a project. Being more agile or more flexible means in practice that systematic checks and balances between the project managers and the customer/ client are institutionalized and much more frequent than in conventional project management. APM assumes, that a lack of information makes it impossible in the beginning of a project to predict its course and to do any kind of upfront analysis. It therefore opts for adapting the project management itself to the customers wishes in regular loops (see picture).

One definition of APM states that it is in essence as "a non-linear, iterative or adaptive approach to project management". The agile style of designing processes and working answered a need in the IT development industry in the beginning of the 1990s. Other definitions in IT development literature state agility to be the ― "continual readiness of a method to rapidly or inherently create change, proactively or reactively embrace change, and learn from change while contributing to perceived customer value (economy, quality, and simplicity), through its collective components and relationships with its environment ".




 * What is the added value of such a method?

Beyond the rather theoretical functions postulated in the definitions, the actual added value for a project management team is to be able to adapt the project during its course to the wishes of the customer – assuming that those change or are being formed throughout time. As T.R. told our group in an interview on APM, some companies calculate extra costs for additional (re-)work on short call into their project costs from the beginning. In that way time remains the uncritical factor. Customers with flexible or open-end budgets are most likely to contract. APM not only is more dynamic in practice by involving the customer but can potentially be cost-saving as it avoids the big, unpleasant surprise in the end when having to repeat the whole exercise because the customer had desired something else.


 * Where does it come from?

Agile project management originally comes from the IT sector where it was invented. As a result, little literature can be found outside that area that tackles APM as a neutral method or in relation to other industries/ business areas. As stated in the research question, it is one endeavour of this study to filter the main characteristics of APM and to see how they could be applied to a non-IT context.

The original document, the bible of the agile development history, so to say, is the Agile Manifesto. It was invented when a group of 12 people calling themselves the "Agile Alliance" got together to find an alternative to the current documentation driven, heavyweight software development process.



As described in the manifesto, the agile objective is to improve the relationship with customers by reducing formalities to start and be more time-efficient, with a strong focus on the customer needs throughout the development process. In addition, APM encourages to enhance communication within teams and envisages to omit writing extensive documentation throughout the project. These principles adopted and transformed to be suited best to the needs and the processes of each organization or industry .

As our interview partners and also other authors regard communication as the key success factor when applying APM. In addition, team capabilities, management support, customer involvement and the strength of the processes play a crustal part in this methodology.

Scrum
Closely relating to the agile principle, scrum is a framework used for project management, which is designed for projects where it is difficult to look ahead. The term ‘scrum’ comes from rugby football. The similarity between sports and project management is that the cooperation as a team is key to overcome an obstacle. Scrum was developed independently of agile and initially was not specifically identified with the software industry but with innovative product development. The ideas that scrum is based upon them were developed in 1990s by Ken Schwaber and Jeff Sutherland.

Given its flexible and agile nature, scrum can take many forms, although the core approach and structure remains. The following is based on Ken Schwaber’s introduction (2007) that worked with Jeff Sutherland to formulate the initial versions of the scrum development process and to present scrum as a formal process at OOPSLA'95.


 * Scrum Roles

Scrum identifies three main roles: the product owner, the scrum master, and the development team. The Product Owner is responsible for the shape of the final product by creating and prioritizing the products requirements and records them in a product backlog. The scrum master acts as a moderator in the meetings, leads team meetings, and describes specific projects. The development team is actually creating the product.


 * Scrum Workflow

Scrum is made up of sprints, which are short durations of time, usually between 2 to 4 weeks, during which the tasks should be completed, and documents with product requirements or prioritized lists of tasks that needs to be completed that are called backlogs.

A sprint has various phases. During the sprint planning meeting the product owner and the development team meet and examine the initial product backlog and they create a sprint backlog – a selection of prioritized activities they believe can be completed within the duration of the sprint. Work now starts. Each day the development team meets for a scrum meeting of about 15 minutes. Team members report individually about (1) work done since the last meeting, (2) work planned for the day and (3) possible obstacles. During the sprint completion there is a sprint review meeting where the development team presents to the product owner and/or the client and other members of management. For the next sprint, some of the tasks in the sprint backlog might be added or removed. The scrum master may hold a sprint retrospective meeting for the future process improvement.


 * Table of Strengths and Weaknesses of APM / Scrum

To answer our first research question on what strenths and pitfalls of APM and scrum are, here is our assessment:


 * Most Dominent Weakness

Besides communication (as already mentioned a couple of times and illustrated from different angles), we identified the lack of documentation as one weakness of APM. This is due to the following arguments, in our opinion: In business, documentation is most relevant in cases where staff fluctuation is high and know how might escape or knowledge sharing is limited due different factors (e.g. communication, climate of confidence, appointments like incorporation and handover of work/ documents before staff exit). In addition, we find that project documentation is also relevant in terms of project controling and goal oriented management. When changes are required very often, a project's progress can go forth and back. If documentation is available, double or triple work could be avoided. Thereby also mistakes and thus risk avoidance can be managed. Therefore, we picked this weakness as the most prominent after communication, as already elavorated above. To solve this documentation problem, some companies introduced a wiki-engine inside the company for these purposes. Every employee, where ever she or he is located, can input knowledge and upload documents to share the know how with their colleagues. (This was reported by one of the students from University of Potsdam who is writing his master thesis together with the company "D-Labs" to put such process for agile software development in place.)

In order to emphasize the advantages of the APM approach we selected two case studies to illustrate the implementation of this method in different environments. However, the focus will be on the waterfall method and APM, the hybrid methods have served as theoretical and practical examples that can stand for themselves and will not be further tackled here. The two case studies are meant to illustrate the challenges and benefits of an organizational transformation from waterfall to APM in practice. This relates back to the research question which asks for the benefits and pitfalls of APM - thus it will be particularly interesting to see, what improvements the introduction of APM have brought to the respective two cases.

=Case studies=

In the first case we will elaborate on the British Telecom's transition from a more traditional project management approach towards an APM way of working. The second case will refer to the British Government implementing the agile method in their organization structure by founding a new department dedicated to digital services. Afterwards, we will also look into different industries and their application of APM - and at how strong the IT-dependency is.

British Telecom’s Transition to Agile

 * Step One - 90-day Delivery Cycles

More or less immediately, all units were required to adopt a standard 90-day delivery cycle that started with intensive 3-days “hot houses”. During those 3 days, cross-functional teams discussed business problems in presence of the main stakeholders. The working prototypes formed the basis of the development activity for the remaining cycle. Such a cycle includes the implementation of the working prototypes, quality control tests and finalize it. For BT, this represented a huge difference from the 12+ month delivery cycles that were previously in place.


 * Step 2 – Business Value Delivery

For each cycle, clear business priorities were set that included a strong emphasis on the end-customer's experience, a shorter response time and transaction success rates. At the end of the cycle, bonus payments to employees were paid based on the assessment. Departments that were failing to add business value over a series of cycles risked to be closed down. In practice, programs often took more than one cycle to progress a suitable solution that fitted for deployment. That is because, although at the end of each cycle an assessment and feedback on what has been delivered so far was given, not everything could be immediately implemented. Some things simply take time to change.


 * Step 3 – Collaborative Approach

The next step was to encourage the continuation of the business and IT departments' collaboration not only in "hot houses" but in everyday work, through design walk-through sessions, prototype reviews, and so on. Collective ownership of the working prototype needed to become the accepted norm, and any practical steps to enhance collaboration should be have been taken. Early reflections of a team member: "Despite some turmoil at the start, and some painful failures among some of the earliest hot houses & delivery cycles, the new practices have now become accepted as the norm across BT. Now well into the second year of its shift from waterfall to agile delivery practices, few people would be willing to revert to pre-Agile practices. In fact, most programs are now seeking ways of refining their delivery processes further by adopting truly iterative & test-driven development practices within each delivery cycle" Ian Evans, British Telecom.


 * The Outcome

Transferring a large IT organization from a waterfall-based delivery method to an agile delivery approach needs patience and time as well as a lot of commitment. It has also transformed the traditional function of the IT department as a supplier of IT services to one where IT is collaborating in business initiatives. Above all, it has created an attitude of delivering real value to the business through IT.


 * Lessons to be Learned from the transformation process at BT

• Establish a group of people that will embrace the agile method and will be able to lead others. • Use outside consultancy to advise within the transformation process. • New approach can be painful to some people or departments. It is important to mandate the use of agile methods in the entire enterprise and not to give up to that. • The business units also need to move away from traditional waterfall practices and change how it engages with the IT department. • A radical change in large company requires total commitment from the management.

British Government Digital Services
Being supervised by a young and open-minded baroness, this department adapted a numbers of agile practices to its core. As the main target of the government is to serve the people, an agile approach suits this case very well. The main purpose of this change was to build relations with all stakeholders such as citizens, ministers, etc.. All the modern functions and services that were gathered under one domain gov.uk, aimed at creating best user experiences. Individual interactions were now facilitated through tools and processes. All the stages of development remained published on the departments blog and everybody was invited to participate in discussions on it. As additional tools they were using kanban cards and different other visualisation methods to smoothen the development process. Any member of the team and other teams could gain insights into the progress and tasks. This helped as well to get a 360 degree feedback.


 * Illustrations

In the following pictures some parts of the process are displayed. Almost everything was visualised, so that anybody could come and oversee the entire process. Live mock-ups were also available during the entire time for testing and discussions as well as hand drawings.


 * Sprint 13

Another initiative that was using agile principles within this project is the so-called "Sprint 13". During the first meeting on 21 January 2013, the projects' managers decided to transform the web portal in 400 days. Ever since then, continuous improvement was taking place. Although services were already running, the team did not stop and still worked on its improvement. They invited ministers, operation officers and others to discuss and share experiences, needs and ideas to make gov.uk more useful and helpful for the UK citizens. Sprint 13 video


 * Evaluation of the Process

In order to see if the transformation of the web portal and the overall application of agile procedures were really worth it, the cons of the Waterfall method will be examined here and contrasted to agile aspects. The pros of the waterfall method are inapplicable here because the project was not limited in time, it is an ongoing process and interactive development is applied for all stakeholders (customers, ministers, operation officers, etc.). The following cons of the waterfall method (see above) will be discussed in detail according to the underlying case.
 * Changes, even at a later stage, can be undertaken easily and adapted to the changing needs of the customer. Each part of the portal was created with consultation from both sides, ministers and users.
 * Customers might not really know what they want at an early stage, but this was eliminated by the process structure. With each iteraction customers came closer to understanding what they needed and the project was adapted accordingly.
 * Quality of analysis of requirements and design is driven by capability to express the customers' thoughts and needs, understanding and transferring the same into generally understood phrases by the project manager (so to say: speaking the same language). With each iteration in agile, both sides began understanding each other more and more, in order to create the best solution. In addition continuous feedback was generated from all stakeholders.
 * Usability of the generated (software) product is created by the team of experts in their fields in cooperation with the customer.
 * Prototypes and mock-ups are used from the early stages of the projects, and everybody can see it in real, touch, try and test it. Pictures, drawings, live versions of portal were available for everybody in the team to try. In that way most of the flaws were eleminated continuously before going public.

=Applicability of APM in Non-IT Related Projects=

After two case studies have been tackled as examples of how APM can be applied in IT related contexts, we will now turn to look at some non-IT business areas and industries. It is not exactly a quantitative research method, but it definitely goes beyond the single case example. Therefore below the consulting business and the exhibition industry will be examined as in how suitable APM could be there and if it is actually applied by some companies. The consulting industry was chosen for slightly different reasons - as none of us has experience working there, but we thought, since the main business is project management, and consulting is extremely close to the customer as well, it might serve as a good example. The exhibition industry was chosen, as one of our group members has extensive work experience in that area and thus not only brings in a lot of knowledge but also evaluated this industry to be suitable for study as it is very customer-oriented and communication-driven. In addition, we would like to investigate, whether it is possible to use APM in an academic environment. For that, we took the chance of examining this group work itself when writing a group term paper in an agile working mode as sample project to test the possibilities and limitations. To verify the validation of our outcome, a second sample group's experiences who was using the same workflow on a different topic has been taken into consideration. The results of this experiment are to be found in the end of this chapter.



APM in Consulting
Assuming that consultant companies are by default very customer-oriented and have to be on top of things when it comes to trends in methodology, innovation and analysis, it would be interesting to shed light on the usage of APM in this area. A paper that examined APM and traditional project management at the hand of the case study of Pricewaterhouse Coopers came to a few interesting conclusions about the way consultant companies work :


 * highly project-dependent, thus excelling at project management is key
 * clients: can be companies and countries. Especially in countries that are highly volatile and thus subjected to a changing environment, APM has an edge and according to the paper is being applied occasionally
 * But: consultants like waterfall. The example of PwC is illustrates, that project management in consultant companies follows rather a rigid waterfall scheme. As risk management is an important part, the risks are assessed in the very beginning of a project - only to then limit the course of a project to a rather strict sequence of steps. The waterfall approach seems to fit the needs here.
 * Aiming at cutting out a clear and comprehensible structure and plan for the client, the consulting company tries to make the ahead lying project as predictable and sequenced as possible - among other reasons to re-assure the clients and to keep the possibility to encounter surprises low. Again, Waterfall seems very suitable for this.

Apart from PwC, further research on whether consulting companies apply APM outside IT development, the results were similar to the above mentioned case study: In the consulting sector APM is not systematically applied outside an IT context. The exception are IT-consulting companies that do offer APM coaching, consulting and implementation support. However, it is always IT-development related and therefore reconfirms the assumption that APM has rarely been isolated yet from the IT context as a "good practice" and been applied in completely different areas.

APM in the Exhibition Management
Exhibitions or trade shows are services that can be B2B or B2C related. In general there are different tasks. For both B2B or B2C the show organizer has to rent a venue, has to be informed about the customers wishes and must then allocate booth locations to the customers etc. Further activities include for example the marketing of the show and operational questions such as to set up a show in general and how to make it a successful show for the customer.

This assessment is based on a theoretical simulation by the project group. The target is to identify opportunities and limitaions for a show organizer to implement APM. There are four ideas that seem to be the most central when examining possibilities to apply APM in this business area:


 * Internal communication: Each period, the show concept changes due to latest trends in the industry, customer wishes for their booths' position within the halls or any other major or minor changes. By applying an agile way of working each team member is informed about major adaptations in others than his or her own working area. The remaining space still available to the customers is all time known to all team members. Problems and issues of interest to the entire team would be pointed out and could deliver problem solving approaches to fellow colleagues in a comparable situation.
 * External communication: Although there is not "one" clear customer, the board of management or show director could be seen as such to report to. Changes upon request would be possible and a regular reporting rhythm is usually in place.
 * Prototyping: Prototyping an exhibition is impossible due to the fact that services in general are produced and consumed at the same time when involving external players - customers, exhibitors and visitors alike. There is no added-value to host a test-exhibition to all participants. It would cost too much time, money and effort. Thus, only parts of this production process like promotional material, hall plans etc. could be prototyped for the customer's or the internal preview.
 * Time: Different to e.g. software development exhibitions have a fixed delivery date, which CANNOT be postponed due to complications in the preparation process. Worldwide industries are planning their production according to the due date. Thus the only flexible factor of APM in the exhibition management is the budget. Activities on short call are therefore not unusual and increase costs.

As shown in the few examples above, exhibition management is a typlical "SCRUM BUT". You could apply scrum or agile features, but only up to a certain level. Organizing exhibitions that have a regulare cycle and circulating tasks within these cycles could make limited use of APM features. This very specific working model will never serve all criteria or features of APM. Nevertheless, it would help to harmonize processes within a company. That means, often different exhibition teams within one company act differently. This is usually justified with the argument that different exhibitions with differing customers need different approaches. However, certain above described activities will always stay the same within all teams. Therefore our recommendation is to apply as many APM features as possible that all teams have in common.

Self-experiment: APM in academic group work
This project has been carried out in an agile way by using the Wikiversity as our worksheet and an agile working mode. Two groups of four students have been formed working on two different topics and over a period of 15 weeks both groups they had to transfer those efforts into a term paper. For that purpose an introductory session was initiated and the basics of APM were introduced.

When this group started working on the project, we had to find our way through the new working process. This was due to the fact that we decided writing the term paper about a topic of interest and to learn a new tool for our personal ‘management tool box’. However, none of us had ever worked in an agile way before. From a practical perspective it was completely new for us.

We kicked off the project by noting down our research question(s), some framing ideas and first tasks. This was our backlog. In weekly meetings with our scrum master, we discussed the progress, the obstacles and how to overcome them. In addition, we divided tasks among us in the initial backlog for the following week. The sprint reviews were done every 3-4 weeks. For that we met with our clients - in this case the professor and the other classmates - and received feedback on our "prototype" and work progress.

Klick here if you want to have a look into our video about how this Wiki-page was used as a prototype in this agile group work and grew throughout the progress

Project Group's Assessment on APM in Academic Group Work

 * Pros for Applying APM in an Academic Environment

The weekly scrum meetings with our scrum master helped us to learn the process itself step by step and give progress reports. In some way, it forced us to work disciplined on the topic because we had a deadline each week. These meetings also gave us the chance to gather feedback from the customers regularly. Some of the feedback revealed that we are on the wrong way and needed some adjustments. The agility of the project and our working tool, Wikiversity, allowed us to change the research question without losing too much time.

We would like to mention that the discussion page on Wikiversity was used as the backlog for our weekly tasks distribution and for general communication with the module lecturer. More than that, working on the common worksheet enhanced our collaboration and encouraged a team spirit and participation. It ensured that the work not overlapped and kept the appropriate flow of the text.

In addition to the process related points above, we would like to point out that Wikiversity served us as a mock-up (prototype). Using it as worksheet gave illustrative dimension to this project, which was missing in other term papers we did during this MBA. As it was possible to review the mock-up at any time and from any place (with internet access), it supported the idea to adapt and work on the term paper in progress at any time to not lose time accordingly.


 * Cons of Applying APM in an Academic Environment

One thing that differed from a work life based APM was the fact that we decided not to appoint a team leader or a scrum master other than the professor. This was based on the fact that the team size was small, easy to handle and all team members knew the others' working approaches, and therefore could deal with that. Furthermore, the team could speak openly about all problems and find solutions for them together. We based our decision making process always on a group agreement. And the professor’s requirements, desires or advises were seen as the scrum master’s and customer’s simultaneously. These joint decisions were sometimes more time consuming and thus slowed down the working speed at few phases. However, the general schedule and weekly reviews set given time frames and compensated it.

Overall everything functioned in an appropriate time frame, task distribution was flexible enough to be adapted and we met the deadline on time.

According to our experience, a recommended team size of up to nine persons appears to be even too high for a group work in an academic environment where the task is to write one coherent text. We experienced our group size of four persons to be appropriate to coordinate and communicate, especially when it came to changes or group decisions. In case the team size is bigger, a scrum master would be recommendable in order to lead the team and force decisions.


 * Limitations

There were two main problems – one concerned the working process and the other one was content related.

During the project period we faced some situations where we were geographically split for more than a week but had to meet deadlines. Sometimes this could be solves through video conferences or online calls, sometimes through more traditional means of communication such as meetings or phone calls. By using alternative online tools like titanpad.com, dropbox.com or the discussion page on our wiki platform we exchanged information whenever it was possible for each person to access the web and solved the problem.

The second challenge we faced, was related to sources that concerned the second part of our initial research question on applicability of APM in a non-Western cultural context. It was hard to find any information at all, hinting at a gap in research at present. Digging deeper or even travelling and making interviews with experts on culture in order to find appropriate material would have cost us too much time for this project. Therefore we decided to make use of the possibility to change the research focus to not risk the superior goal. Accordingly the cultural aspect was ommitted.


 * Conclusion: APM Can be Easily Applied in Academic Group Work

The agile working mode motivated us to try a new way of creating a usual academic term paper. We liked the idea to apply and train an agile working method in an academic environment with small group sizes, as this combines the usage of tools sharing information publicly and being online accessible. Essential elements of scrum like backlogs, sprints, sprint reviews and specific roles such as the scrum master or the customer can be transferred from theory to practice if appropriate. The agile working mode gave us more freedom to adapt and react to changing circumstances very quickly. An online tool like Wikiversity can generally function as prototype for evaluating the customer’s desire of the ideal end-product. Agile project management should definitely be applied more often, from our point of view.

Validation of Findings (Feedback from Second Project Group)
Below is a summary of the most important findings the second project group experienced while executing group work with the help of APM.

Motivation Level
 * Was much higher compared to other group projects within the semester
 * APM working mode made it more interesting and incentivized them to learn something new
 * Apparently it took a couple of days to fully understand and work in the working mode in terms of how to communicate, when to deliver what and how to deal with changes

Communication
 * Communication is key!!!
 * Means of communication were mainly meetings in person on a weekly basis
 * Used sprint reports as external reporting tool for valueable feedback from scrum master and customers
 * TitanPad worked as platform to exchange information

Scrum Elements
 * Applied the same elements
 * TitanPad functioned as back-log to distribute tasks
 * Progress Reports were placed in Wiki discussion page



Generally speaking, the findings of the second sample group were similar and overlapping with ours. This leads us to the conclusion, that our findings on the experience of applying APM in an academic environment seems to be valid and realistic. For a broader validation, further research would be necessary. Because we jointly decided to split only into two groups (each four members), no other peer group was available to compare experiences. We regard the small sample as one limitation of our research. Additional feedback could be generated from further student groups working in an APM / scrum way in near future.

Comparison of Traditional Project Management Methodology with APM
As shown beforehand, we have explained what APM in theory is and how it is applied nowadays in certain industries - or where it is not applied. For the final sprint review of our project, we created a table contrasting waterfall project management and APM both in academic group work. Waterfall is the commonly used working approach within most of our MBA working groups. After we have found out a lot regarding APM (theory as well as practical issues as some results of our paper) and experienced working in an agile mode for this project ourselves, we compared both working styles. We would like to point out that this table is neither exhaustive nor exclusive. It is only a self-reflecting summary of things we found most important. Furthermore, the table illustrates a single group experience in specific situations and should be understood as a basis for further discussion and exchange.


 * Criteria Definition

To evaluate our experience we agreed on the following criteria for a comparison:

GIVEN TIME LIMITATIONS – means a limited time frame, fixed deadline until when the paper has to be finalized and time constraints due to work load within the semester / other modules.

BUDGET CONSTRAINTS – means budget in teams of real money or opportunity costs for participants in this project.

NEED FOR PROTOTYPING (MOCK-UP) – the usefulness of a prototype for the success / practicability of the working method.

TASK LIST (BACK-LOG) – whether task lists are useful or necessary for the project management method.

INTERNAL AND EXTERNAL REPORTING STANDARD – discusses how the methodology deals with the institutionalization of communication and reporting ways in general.

TEAM SIZE (> 4 PERSONS)

ADAPTABILITY TO CHANGE – how easy is it to make changes in the working mode discussed.

COMPREHENSIBILITY – gives an answer to whether a new method can be understood and applied easily by students having limited knowledge about it.

DOCUMENTATION MANAGEMENT – means the possibility to track the working process and go back to an earlier version easily.


 * Group Evaluation

Overall, our evaluation and rating of both methodologies is balanced. We found out, that for large group sizes with more than four persons the waterfall approach would be beneficial. If the group size is limited to four students, the APM approach would add value to lectures and modules in university, making group work more interesting and inspiring. The agile method can definitely score for research projects for which the target or goal is not clear at the beginning and will shape up over time.

Conclusion on Applicability of APM in Other Industries
After having shed light on two customer oriented industries and having assessed our self-experiment, these are our key-findings:

Consulting: Although consulting itsef should be customer oriented, flexible and therefore APM could be an ideal methodology, APM is not systematically applied outside an IT context. We found only examples of IT-consulting companies that do offer APM coaching, consulting and implementation support.

Exhibition Management: It is a typlical "SCRUM BUT" field. Scrum or agile features can be applied, but only up to a certain level due to a logical set up and work flow. By illustrating a couple of working phases in the exhibition organization, we found out that organizers could make limited use of APM features. Therefore our recommendation is to apply as many APM features as possible to be as customer oriented and flexible as possible.

Self-Experiment "Academic Group Work": APM can be applied in academic group work. The agile working mode motivated us throughout the project and we liked the idea of applying and training an agile working method in an academic environment with small group sizes. The method gives students freedom to adapt and react to changing circumstances very quickly and use Wiki as a prototype. This assessment was acknowledged by a second group working in an agile mode on a different topic. By comparing the advantages and disadvantages of the sequential waterfall approach with the more flexible APM approach, we found out that both methodologies are balanced. Here it depends again on the project type, whether the overall goal is already decided at the beginning of the project, as well as the group size of the teams. In any case, APM is an interesting and inspiring way of getting students actively involved.

Therefore, we can conclude that, in areas we highlighted, APM has rarely been isolated yet from the IT context as a "good practice" and been applied in completely different areas. Thus, and due to its advantages, it is time to introduce it to the academic environment on a broader scale.

=Project Conclusions=

This project has been a bit of a time journey throughout different stages and models of project management arising from various epoches or necessities. With the IT industry growing and professionalizing, the agile approach and models like APM/ scrum have been developped and are increasingly applied especially in sooftware development. The main attributes are dynamic and flexibility here, characteristics inherent to agile approaches, tailored to the prerequisites of software development. Besides the theoretically useful aspects for working environments other than IT, this paper could not validate the assumption that agile or scrum is applied in other industries at large. Waterfall is more prominent, still.

Having looked at the theoretical aspects of project management methods and the industries where they are applied, one of our main conclusions is to be more open to experiments and try to at least apply parts of the agile method and scrum in other areas, too. Whereever prototypes are necessary or relevant and a team or company is facing a volatile environment, applying agile working modes might be part of the solution.

After theoretically concluding this, we were able to confirm this with our own experience, as this paper has been coordinated and written in an agile working mode. To our taking the adaptability throughout the process and the institutionalized communication and feedback from the professor helped during the process and also led to more resilient and reliable results. This was also acknowledged by a second groups' assessment. Besides, it is a more innovative and interactive way of learning for the students.

To sum it up: Waterfall and APM/ scrum are suitable for different types of projects. Specific requirements call for specific features and one has to take the strengths and weaknesses of both methods into account.

=References=