DTU ProjectLab - User contributions [en-gb]

Manage Extreme Projects with Rapid Methodology

2015-09-28T16:58:43Z

S141926: /* Dealing with high levels of uncertainty */

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical guide for the next millennium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptive Project Framework. Managing complexity in the face of uncertainty. Pearson Education, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it. So there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical guide for the next millennium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===

They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful any more. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===

[[File:rapidmeth.jpg |thumb||right||450px|Speed, changes and uncertainty diagram <ref name=decar />]]
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. <ref name=mc/> For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.

It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

In Extreme Projects plan-changing successes occur while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model]. This model is characterized for being a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.<ref name=mc/>

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed above that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion of successful implementation and limitations==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

In terms of limitations, most of the previous characteristics can be recalled here if they are not fulfilled during a project. For instance, it has been mentioned that a key point is carrying out regular meetings with stakeholders, the lack of willingness or availability to do so becomes a limitation of the method. Other facts worth mentioning of implementing Rapid Methods on Extreme Projects follow.

The fact that it depends to a large extend on the individual performances, skills and abilities to overcome uncertainty might be a disadvantage of this method. Highly qualified and experienced team is needed to identify requirements and redirect the project when changes occur. Moreover, this method will not be a success if the team is not motivated enough nor willing to collaborate together as part of a team.

Previously it has been mentioned that high qualified and skilled team members are needed, but not only the technical/managing knowledge is important here. Personal behaviour and attitude are key elements when all implied parties are sat together to discuss a change/success. That is something that one might not be able to find in the candidates CV but that will be an important asset for successfully manage a project with a good, and crucial, working atmosphere.

== References ==

<references />

'''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

'''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.'''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

'''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.'''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

'''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.'''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

'''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.'''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

'''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.'''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

Talk:Manage Extreme Projects with Rapid Methodology

2015-09-28T16:54:43Z

S141926:

== Review given by StephSalling, review2 ==
==== Formal aspects ====
* The article follows the “method” structure very well.
** ✓
* There are some grammatical, spelling and punctuation errors, maybe an extra proofreading would be a good idea (maybe by someone else, it is often helpful having a second pair of eyes read it through).
** I have to say that I absolutely agree with you. After extra proofreading I made same changes that, I think, made the text more understandable and easier to follow.
* The article is written in an engaging style in terms of content, but some sentences are a bit long and hard to follow.
** Same I said above applies here :)
* The figure is very illustrative, but a reference to the source for it might be a good idea. More figures would improve the reading experience, but I do not know if it is possible to find other relevant figures.
** I drew the figure myself but I was inspired from DeCarlo's book so as you said it is a good idea to reference it. I also added a new figure to illustrate the uncertainty explained in the second section. Good suggestion.
* Very nice use of table and bullet points.

==== Content aspects ====
* I think the article is interesting for a practitioner.
* The topic is clear and specific.
* The length of the article seems appropriate.

* There is a red thread through the article, however, the transition from XPM to Rapid Methodology could be smoother.
** I don't exactly know what you mean by "red thread" but I tried to make a more smoother transition with a short introduction.
* The starting summary is sufficient and not too long.
** ✓
* Your sources seem good and of high quality. You could maybe elaborate some of them (the “annotated bibliography” part).
** ✓ I forgot to annotate the bibliography like the assignment says, thank you for telling!
* The use of the word “we” in some sentences is a bit confusing for me as it mixes up your “own opinion” with statements substantiated by literature.
** ✓ Even though I only found one "we" you are right, it sounded a little confusing so I rewrite not only this sentence but also other statements that sounded own opinion while were not. Thank you for the constructive feedback.

== Reviewer 3: s141586 ==

In general, very good article with an interesting topic and good flow, but needs improvement. 
Formal: 
• The article follows a clear “method” structure. 
• In general, too long sentences. I have detected many grammatical errors, needs proofreading. 
* As I said to the reviewer 1, I have to say that you are also absolutely right. After extra proofreading I made same changes that, I think, made the text more understandable and easy to follow. Regarding the grammatical errors, I found some misspelling and mismatching between verb and subject. Hope it looks better now.
• The use of the form “we” it does not sounds very good in an academic article, I would rather use the passive form to express the same (Overview section) 
* This was also suggested for reviewer one, and I agree with you both. The sentence has been rewritten.
• Well-referenced and good use of quotes from authors. 
• Some more figures would be useful 
* ✓
• Well formatted. Wiki references. 

Content: 
• It is a very interesting topic for a practitioner, but I have the feeling that some of the statements are being repeated in too many paragraphs (specially the ones defining the XPM). 
* I understand your point of view, my intention was to quickly introduce the concept and develop it further in the article. But I agree with you that some definitions were a little repetitive. I found some redundant sentences that have been deleted so I hope it does not look that repetitive now. Good suggestion.
• The length seems to be ok, even that is around 2500 words. It has a good flow. 
*✓ After your suggestions some text has been added so now it is nearly 3000.
• I miss a “limitations” paragraph, were you explain the weaknesses of the XPM or when to apply it. 
* The limitations where kind of defined in the discussion but maybe not developed enough. I rewrote this section and I believe that now the limitations are more detailed. Good suggestion.
• In general, I think it is a good idea to find some examples of XPM projects, and explain a little about one or two cases. 
* In my opinion this might be a good idea if the only topic in this report was XPM. However, my intention for this article was to "briefly" describe what XPM are and afterwards focusing more on Rapid Methods to manage them.
• I think it would be good to describe each of the sources with few lines, explaining about the paper and the author. 
* ✓ I forgot to annotate the bibliography like the assignment says, thank you for telling!
• It is hard to distinguish between your opinion and the theory; maybe you should clarify it in the discussion section. 
* Good point. I hope that the changes made improved this aspect.

S141926. Thank you both for your constructive and clear reviews. They have been very useful to improve the article.

Talk:Manage Extreme Projects with Rapid Methodology

2015-09-28T16:34:31Z

S141926:

== Review given by StephSalling, review2 ==
==== Formal aspects ====
* The article follows the “method” structure very well.
** ✓
* There are some grammatical, spelling and punctuation errors, maybe an extra proofreading would be a good idea (maybe by someone else, it is often helpful having a second pair of eyes read it through).
** I have to say that I absolutely agree with you. After extra proofreading I made same changes that, I think, made the text more understandable and easier to follow.
* The article is written in an engaging style in terms of content, but some sentences are a bit long and hard to follow.
** Same I said above applies here :)
* The figure is very illustrative, but a reference to the source for it might be a good idea. More figures would improve the reading experience, but I do not know if it is possible to find other relevant figures.
** I drew the figure myself but I was inspired from DeCarlo's book so as you said it is a good idea to reference it. I also added a new figure to illustrate the uncertainty explained in the second section. Good suggestion.
* Very nice use of table and bullet points.

==== Content aspects ====
* I think the article is interesting for a practitioner.
* The topic is clear and specific.
* The length of the article seems appropriate.

* There is a red thread through the article, however, the transition from XPM to Rapid Methodology could be smoother.
** I don't exactly know what you mean by "red thread" but I tried to make a more smoother transition with a short introduction.
* The starting summary is sufficient and not too long.
** ✓
* Your sources seem good and of high quality. You could maybe elaborate some of them (the “annotated bibliography” part).
** ✓ I forgot to annotate the bibliography like the assignment says, thank you for telling!
* The use of the word “we” in some sentences is a bit confusing for me as it mixes up your “own opinion” with statements substantiated by literature.
** ✓ Even though I only found one "we" you are right, it sounded a little confusing so I rewrite not only this sentence but also other statements that sounded own opinion while were not. Thank you for the constructive feedback.

== Reviewer 3: s141586 ==

In general, very good article with an interesting topic and good flow, but needs improvement. 
Formal: 
• The article follows a clear “method” structure. 
• In general, too long sentences. I have detected many grammatical errors, needs proofreading. 
* As I said to the reviewer 1, I have to say that you are also absolutely right. After extra proofreading I made same changes that, I think, made the text more understandable and easy to follow. Regarding the grammatical errors, I found some misspelling and mismatching between verb and subject. Hope it looks better now.
• The use of the form “we” it does not sounds very good in an academic article, I would rather use the passive form to express the same (Overview section) 
* This was also suggested for reviewer one, and I agree with you both. The sentence has been rewritten.
• Well-referenced and good use of quotes from authors. 
• Some more figures would be useful 
* ✓
• Well formatted. Wiki references. 

Content: 
• It is a very interesting topic for a practitioner, but I have the feeling that some of the statements are being repeated in too many paragraphs (specially the ones defining the XPM). 
• The length seems to be ok, even that is around 2500 words. It has a good flow. 
*✓ After your suggestions some text has been added so now it is nearly 3000.
• I miss a “limitations” paragraph, were you explain the weaknesses of the XPM or when to apply it. 
* The limitations where kind of defined in the discussion but maybe not developed enough. I rewrote this section and I believe that now the limitations are more detailed. Good suggestion.
• In general, I think it is a good idea to find some examples of XPM projects, and explain a little about one or two cases. 
• I think it would be good to describe each of the sources with few lines, explaining about the paper and the author. 
* ✓ I forgot to annotate the bibliography like the assignment says, thank you for telling!
• It is hard to distinguish between your opinion and the theory; maybe you should clarify it in the discussion section. 
* Good point. I hope that the changes made improved this aspect.

S141926. Thank you both for your constructive and clear reviews. They have been very useful to improve the article.

Talk:Manage Extreme Projects with Rapid Methodology

2015-09-28T16:31:46Z

S141926:

== Review given by StephSalling, review2 ==
==== Formal aspects ====
* The article follows the “method” structure very well.
** ✓
* There are some grammatical, spelling and punctuation errors, maybe an extra proofreading would be a good idea (maybe by someone else, it is often helpful having a second pair of eyes read it through).
** I have to say that I absolutely agree with you. After extra proofreading I made same changes that, I think, made the text more understandable and easier to follow.
* The article is written in an engaging style in terms of content, but some sentences are a bit long and hard to follow.
** Same I said above applies here :)
* The figure is very illustrative, but a reference to the source for it might be a good idea. More figures would improve the reading experience, but I do not know if it is possible to find other relevant figures.
** I drew the figure myself but I was inspired from DeCarlo's book so as you said it is a good idea to reference it. I also added a new figure to illustrate the uncertainty explained in the second section. Good suggestion.
* Very nice use of table and bullet points.

==== Content aspects ====
* I think the article is interesting for a practitioner.
* The topic is clear and specific.
* The length of the article seems appropriate.

* There is a red thread through the article, however, the transition from XPM to Rapid Methodology could be smoother.
** I don't exactly know what you mean by "red thread" but I tried to make a more smoother transition with a short introduction.
* The starting summary is sufficient and not too long.
** ✓
* Your sources seem good and of high quality. You could maybe elaborate some of them (the “annotated bibliography” part).
** ✓ I forgot to annotate the bibliography like the assignment says, thank you for telling!
* The use of the word “we” in some sentences is a bit confusing for me as it mixes up your “own opinion” with statements substantiated by literature.
** ✓ Even though I only found one "we" you are right, it sounded a little confusing so I rewrite not only this sentence but also other statements that sounded own opinion while were not. Thank you for the constructive feedback.

== Reviewer 3: s141586 ==

In general, very good article with an interesting topic and good flow, but needs improvement. 
Formal: 
• The article follows a clear “method” structure. 
• In general, too long sentences. I have detected many grammatical errors, needs proofreading. 
** As I said to the reviewer 1, I have to say that you are also absolutely right. After extra proofreading I made same changes that, I think, made the text more understandable and easy to follow. Regarding the grammatical errors, I found some misspelling and mismatching between verb and subject. Hope it looks better now.
• The use of the form “we” it does not sounds very good in an academic article, I would rather use the passive form to express the same (Overview section) 
** This was also suggested for reviewer one, and I agree with you both. The sentence has been rewritten.
• Well-referenced and good use of quotes from authors. 
• Some more figures would be useful 
** ✓
• Well formatted. Wiki references. 

Content: 
• It is a very interesting topic for a practitioner, but I have the feeling that some of the statements are being repeated in too many paragraphs (specially the ones defining the XPM). 
• The length seems to be ok, even that is around 2500 words. It has a good flow. 
**✓ After your suggestions some text has been added so now it is nearly 3000.
• I miss a “limitations” paragraph, were you explain the weaknesses of the XPM or when to apply it. 
** The limitations where kind of defined in the discussion but maybe not developed enough. I rewrote this section and I believe that now the limitations are more detailed. Good suggestion.
• In general, I think it is a good idea to find some examples of XPM projects, and explain a little about one or two cases. 
• I think it would be good to describe each of the sources with few lines, explaining about the paper and the author. 
** ✓ I forgot to annotate the bibliography like the assignment says, thank you for telling!
• It is hard to distinguish between your opinion and the theory; maybe you should clarify it in the discussion section. 
** Good point. I hope that the changes made improved this aspect.

S141926. Thank you both for your constructive and clear reviews. They have been very useful to improve the article.

Manage Extreme Projects with Rapid Methodology

2015-09-26T13:54:55Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical guide for the next millennium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptive Project Framework. Managing complexity in the face of uncertainty. Pearson Education, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it. So there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical guide for the next millennium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===

They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful any more. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===

[[File:rapidmeth.jpg |thumb||right||450px|Speed, changes and uncertainty diagram <ref name=decar />]]
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. <ref name=mc/> For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.

It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model]. This model is characterized for being a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.<ref name=mc/>

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed above that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion of successful implementation and limitations==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

In terms of limitations, most of the previous characteristics can be recalled here if they are not fulfilled during a project. For instance, it has been mentioned that a key point is carrying out regular meetings with stakeholders, the lack of willingness or availability to do so becomes a limitation of the method. Other facts worth mentioning of implementing Rapid Methods on Extreme Projects follow.

The fact that it depends to a large extend on the individual performances, skills and abilities to overcome uncertainty might be a disadvantage of this method. Highly qualified and experienced team is needed to identify requirements and redirect the project when changes occur. Moreover, this method will not be a success if the team is not motivated enough nor willing to collaborate together as part of a team.

Previously it has been mentioned that high qualified and skilled team members are needed, but not only the technical/managing knowledge is important here. Personal behaviour and attitude are key elements when all implied parties are sat together to discuss a change/success. That is something that one might not be able to find in the candidates CV but that will be an important asset for successfully manage a project with a good, and crucial, working atmosphere.

== References ==

<references />

'''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

'''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.'''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

'''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.'''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

'''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.'''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

'''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.'''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

'''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.'''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

Manage Extreme Projects with Rapid Methodology

2015-09-26T13:14:16Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
[[File:rapidmeth.jpg |thumb||right||450px|Speed, changes and uncertainty diagram <ref name=decar />]]
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. <ref name=mc/> For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.<ref name=mc/>

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==

<references />

'''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

'''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.'''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

'''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.'''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

'''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.'''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

'''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.'''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

'''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.'''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

File:Rapidmeth.jpg

2015-09-26T13:11:20Z

S141926:

File:Ser.JPG

2015-09-26T13:10:14Z

S141926: sefk

sefk

Manage Extreme Projects with Rapid Methodology

2015-09-26T13:09:09Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
[[File:ser.jpg|thumb||right||300px|Speed, changes and uncertainty diagram <ref name=decar />]]
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==

<references />

'''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

'''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.'''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

'''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.'''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

'''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.'''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

'''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.'''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

'''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.'''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

File:Capture.JPG

2015-09-26T13:03:34Z

S141926: S141926 uploaded a new version of "File:Capture.JPG"

Manage Extreme Projects with Rapid Methodology

2015-09-26T13:03:16Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
[[File:Capture.jpg]] |thumb||right||300px|Speed, changes and uncertainty diagram <ref name=decar />]]
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==

<references />

'''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

'''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.'''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

'''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.'''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

'''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.'''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

'''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.'''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

'''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.'''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

Manage Extreme Projects with Rapid Methodology

2015-09-26T13:02:32Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
[[File:capture.jpg]] |thumb||right||300px|Speed, changes and uncertainty diagram <ref name=decar />]]
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==

<references />

'''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

'''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.'''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

'''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.'''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

'''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.'''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

'''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.'''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

'''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.'''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

File:Capture.JPG

2015-09-26T13:01:07Z

S141926: S141926 uploaded a new version of "File:Capture.JPG"

Manage Extreme Projects with Rapid Methodology

2015-09-25T14:23:40Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==

<references />

'''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

'''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.'''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

'''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.'''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

'''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.'''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

'''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.'''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

'''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.'''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

Manage Extreme Projects with Rapid Methodology

2015-09-25T14:22:55Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==
<references />

'''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

'''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.'''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

'''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.'''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

'''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.'''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

'''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.'''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

'''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.'''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

Manage Extreme Projects with Rapid Methodology

2015-09-25T14:20:54Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==
<references />

''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

''Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing.''

''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

Manage Extreme Projects with Rapid Methodology

2015-09-25T14:18:41Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wyssecond/> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==
<references />

''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.''

Steve McConell is an expert in Rapid Development Techniques and his book has been the main source of the knowledge acquired in Rapid Development and source of inspiration for the 4 factors chart created in the present article. The author provides a list of classic mistakes to avoid that have been useful for providing the recommendations on how to overcome unexpected issues.

''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.''

This book, also from Wysocki has been read in order to understand that the attitude of the people working on a Extreme Project needs to change in order not to become frustrated and stressed, and how the manager can help them to change the mindset of them in order not to suffer during the project but enjoy throughout the project.

Manage Extreme Projects with Rapid Methodology

2015-09-25T13:54:12Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

[[File:drawing.jpg |thumb||right||300px|Approaches representation]]

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes discussed abov that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==
<references />

''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.''

While searching for Extreme Project Managements, Doug DeCarlo is always showing up either as an active writer of the article/book or repeatedly mentioned as a source and important person in the area. This book in particular was very useful while writing this article due to the large amount of information written in a very understandable manner so even without being an expert at this one can easily follow the explanations. In the present article, this book has been an inspiration for the overview and description of Extreme Projects as well as the comparison with traditional methods.

''DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing.''

Another book of the same author has been used as a source. DeCarlo has also carried a number of researches concerning the managing of teams. In the present article one of his founding has been references for the analysis of the different factors concerning rapid methods. Some research done by the DeCarlo proved that people has the largest impact on both the productivity and quality of a project.

''Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis.''

This source has been used to understand and achieve knowledge in order to be able to write about the XPM techniques and to identify the differences between managing a project with XPM and the Waterfall Model. It has been also been useful for getting a deeper understanding of the limitations of the waterfall model.

''Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker.''

This book is focused on the differences between Traditional Project Management Methodologies and Practical Project Management Methodology. Even though the second is not the alternative of the traditional method studied here it has been a good source to understand the limitation that the traditional approaches have.

''McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press.''

Large guide
''Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing.''

''Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc.''

Talk:Critical chain project management (CCPM)

2015-09-22T19:21:31Z

S141926:

Anna: Good choice of topic, remember to be focused on the tool aspect and be very very concrete with the explanation so that your article can help other students understand and use this method.
Remember to follow the structure and include application and limitations.

== Review of S141926, Reviewer 3 ==
I think it is a good and well written article about Critical Chain Project Management, providing a good understanding of the method in a clear and well-structured way.

=== General formal aspects ===
* I think the article is well structured, giving a good understanding of the methodological basis by providing information about the main aspects. Maybe the use of some bullet points would make this part more clear, under my point of view.
* The article engages the reader thanks to the fact that is easily readable, I think the use of the bullet points and subcategories help a lot to that with a logical and easy to follow work flow.
* Good reference notation and format.
* When mentioning methods/concepts that have a Wikipedia article it might be a good idea to link them.
* Grammatically correct with good punctuation and use of technical vocabulary. However, I could read some informal contractions that under my point of view should be avoided in this sort of writing.

=== Review of the content ===

* The article covers successfully the course requirements for a method article. Good description, application and limitations by giving a number of reliable references well notated throughout the whole article.
* Under my point of view, the history part is too long and maybe irrelevant here. I think there is too much personal information about Eliyahu M. Goldratt that might not be much relevant for the purpose of the article. Personally, I would not add his portrait :)
* The core principles are very well defined, using technical and precise language. Without too long and unnecessary sentences. If I had to suggest something it would be adding text formatting before starting the description of each factor (like bold titles).
* Nice and useful illustrations that make more understandable the process and the article more attractive to the reader
* The length of the article seems appropriate and covers all the requirements of the method-article under my point of view. There is a good continuity throughout the article and under my point of view not unnecessary long sentences.
* Clear and well defined procedure to create a CCPM schedule, with examples to make it understandable to the reader.
* It provides a good understanding of the tool and real life examples (Japan section)
* Sometimes it is a bit difficult to differentiate between statements from literature and own opinion
* Good summary of advantages and disadvantages with . However, I would add some more limitations and/or how to overcome them. I would also suggest to add some bullet points or bold format to differentiate the sub-parts.

Talk:Lean as a project management tool

2015-09-22T19:19:27Z

S141926:

Mette: I like the idea and the topic you have chosen. As you write Lean contains many tools, so you could maybe consider if you should focus on only one tool in case of not getting your hands too full. It would still be possible to look at the questions you have presented by only looking at one tool.

==Review1 given by S152093==
* Good article overall. I learned something from it, and it was very informative. A few typos here and there, but there is a full week to correct that :-) In my eyes it gives a very good overview, which is really good. Alternatively you could have chosen a specific area to go in depth with. A few specific comments:
* In “the Lean Structure” I think it would be a little easier to get an overview if the titles were included in the bullets, instead of only in the picture. The picture is really good though, as it gives a quick overview.
* In the next section the titles would be nice as well, but then in the section about how lean can be used as a tool it is included, and that is nice.
* If possible, link to other articles under Gantt chart, QCD-triangle etc.
* When the different parts of the Lean philosophy is described, it would be very useful for me to have the different steps compared to the “traditional” PM methods. You do it at the end of the article, but it would create an easier understanding for me, if there were some concrete examples on where it differs.
* You mention that other PM methods could be more useful in the conclusion. It would be really nice with an example of that, either here or somewhere else in the article.
* Maybe a little more talk about the limitations?
* The figures are good, but the aren't referred to, and that makes them unnecessary as it is right now. In my eyes, they need to be referred to and included in the text, if they are there.
* The three sections, “The Lean Stucture”, “What is Lean as a project management tool?”, and “How can Lean be use as a project management tool?” are a little repetitive to me. Maybe to write it into less sections, or a little more defined outline of the sections would make it a little more clear to me.
* The bibliography is missing the part from the structure “Summarize and outline the relevance of each reference to the topic”.

== Review of S141926, Reviewer 2 ==
I think it is a good and well written article about Lean, providing a good understanding of the tool in a clear and structured way.

=== General formal aspects ===
* I would suggest to review grammatical aspects, I could find some inaccuracies like subject-verb disagreement
* Good structure. Clear and well-structured article, with good introduction/history, overview of the tool and then more specific aspects of the use of it as management tool.
* The article engages the reader thanks to the fact that is easily readable, I think the use of the bullet points and subcategories help a lot to that with a logical and easy to follow work flow.
* Good reference notation and format. In case the figures attached are taken from some source I would add its reference to the caption.
* When mentioning methods/concepts that have a Wikipedia article it might be a good idea to link them.

=== Review of the content ===
* Nice illustrations that make more understandable the process and the article more attractive to the reader.
* The length of the article seems appropriate and covers all the requirements of the method-article under my point of view. There is a good continuity throughout the article and under my point of view not unnecessary long sentences.
* Sometimes it is a bit difficult to differentiate between statements from literature and own opinion
* Clear and well defined processes to use Lean as a management tool.
* It provides interesting recommendations to avoid counterproductive issues if one is to use the tool.
* It provides a good understanding of the tool and how to use it.
* Under my point of view the Discussion part is a little poor. I think it could be a good idea to mention and describe the main benefits of using this tool compared to other methods.
* Also, I think it would improve the article and also meet the course requirements to describe more specifically the limitations and the problems that might arise if using this tool inappropriately.

Talk:Lean as a project management tool

2015-09-22T19:19:06Z

S141926:

Mette: I like the idea and the topic you have chosen. As you write Lean contains many tools, so you could maybe consider if you should focus on only one tool in case of not getting your hands too full. It would still be possible to look at the questions you have presented by only looking at one tool.

==Review1 given by S152093==
* Good article overall. I learned something from it, and it was very informative. A few typos here and there, but there is a full week to correct that :-) In my eyes it gives a very good overview, which is really good. Alternatively you could have chosen a specific area to go in depth with. A few specific comments:
* In “the Lean Structure” I think it would be a little easier to get an overview if the titles were included in the bullets, instead of only in the picture. The picture is really good though, as it gives a quick overview.
* In the next section the titles would be nice as well, but then in the section about how lean can be used as a tool it is included, and that is nice.
* If possible, link to other articles under Gantt chart, QCD-triangle etc.
* When the different parts of the Lean philosophy is described, it would be very useful for me to have the different steps compared to the “traditional” PM methods. You do it at the end of the article, but it would create an easier understanding for me, if there were some concrete examples on where it differs.
* You mention that other PM methods could be more useful in the conclusion. It would be really nice with an example of that, either here or somewhere else in the article.
* Maybe a little more talk about the limitations?
* The figures are good, but the aren't referred to, and that makes them unnecessary as it is right now. In my eyes, they need to be referred to and included in the text, if they are there.
* The three sections, “The Lean Stucture”, “What is Lean as a project management tool?”, and “How can Lean be use as a project management tool?” are a little repetitive to me. Maybe to write it into less sections, or a little more defined outline of the sections would make it a little more clear to me.
* The bibliography is missing the part from the structure “Summarize and outline the relevance of each reference to the topic”.

== Review of S141926, Reviewer 2 ==
I think it is a good and well written article about Lean, providing a good understanding of the tool in a clear and structured way.

== General formal aspects ==
* I would suggest to review grammatical aspects, I could find some inaccuracies like subject-verb disagreement
* Good structure. Clear and well-structured article, with good introduction/history, overview of the tool and then more specific aspects of the use of it as management tool.
* The article engages the reader thanks to the fact that is easily readable, I think the use of the bullet points and subcategories help a lot to that with a logical and easy to follow work flow.
* Good reference notation and format. In case the figures attached are taken from some source I would add its reference to the caption.
* When mentioning methods/concepts that have a Wikipedia article it might be a good idea to link them.

== Review of the content ==
* Nice illustrations that make more understandable the process and the article more attractive to the reader.
* The length of the article seems appropriate and covers all the requirements of the method-article under my point of view. There is a good continuity throughout the article and under my point of view not unnecessary long sentences.
* Sometimes it is a bit difficult to differentiate between statements from literature and own opinion
* Clear and well defined processes to use Lean as a management tool.
* It provides interesting recommendations to avoid counterproductive issues if one is to use the tool.
* It provides a good understanding of the tool and how to use it.
* Under my point of view the Discussion part is a little poor. I think it could be a good idea to mention and describe the main benefits of using this tool compared to other methods.
* Also, I think it would improve the article and also meet the course requirements to describe more specifically the limitations and the problems that might arise if using this tool inappropriately.

Talk:Lean as a project management tool

2015-09-22T19:18:45Z

S141926: /* Review1 given by S152093 */

Talk:Leadership styles

2015-09-22T19:16:34Z

S141926: /* General formal aspects */

Anna: Hi I like the idea, however, I'm afraid that it doesn't really fit into either one of the two article types. This is not really a method, but you could easily choose a method within the topic of leadership.

== Review of S141926, Reviewer 1 ==
==== General formal aspects ====
* Overall the writing is clear and precise with the use of appropriate technical words. However, I found some words mistranslated from Danish and minor grammatical issues.
* In my opinion, I think it would make the article easier to be read if you added more full stops and you split the, under my point of view, too long paragraphs. I liked the paragraph where you make questions and answer them. However, I think that this part would be clearer in bullet points (under my point of view).
* As I mention in the following section, the limitations/solutions part could be nicely shown in a format table to make the article more readable as well as adding some graphics to illustrate the methodology.
* I suggest you to review the Wikipedia formatting, I can see some references and links not well defined or linked.

==== Review of the content ====
* Regarding the Introduction part I think that gives a too general conclusion and does not focus enough to the main topic of the article, which is Leadership styles. Under my point of view, it is too focused on Standards and Managers competences and I am missing some more specific information about leadership in general.
* I think it would also improve your article to get more into detail on the different skills required for a project manager under different scenarios.
* Apart from the fact that as I said I think there is some information missing that would make the article more understandable, I think that you would also had to add some more writing in order to fulfil the requirements regarding length.
* I would advise to review the requirements of the article type and adding a method regarding leadership and define the uses/limitations of this particular method.
* I liked the limitations and problems pointed out when saying that a manager does not have to possess technical skills in the project he/she manages and all problems that come up due to this matter. I found the information given interesting but it might be a good idea to type those problems/solutions in a tabular format or in separated paragraphs.
* I think it would be a good idea to add some more conclusions. However, I found the ones you mentioned relevant and a good summary of the above explained.
* Remember also to add the references part, I am afraid it is compulsory :) And maybe a Table of contents at the beginning.

== Review given by StephSalling, review3 ==
As far as I can tell, this article is not done yet, so I will possibly point out some things you were already planning to change or add.

==== Formal aspects ====
* The different parts in this “method” study are a bit hard to tell apart. The “big idea” is combined with the “application”, but none of them are really adequately described. From my point of view, the “limitations” part in the article is the best part, but it should be substantiated with some literature.
* The grammar, spelling and punctuation in the “introduction” and “conclusion” are generally good: There are only a few singular/plural mistakes. It seems that the “limitations” part has not been proofread as thoroughly as the other sections.
* Even though there are not many fill words in the sentences (which is very good), some of the sentences are a bit long and hard to follow. Maybe some bullet points illustrating the content of the different standards would help make it easier to read. - Or simply dividing the text into more paragraphs.
* Some illustrations of the content of the different standards could be helpful.
* With the many different standards mentioned and technical terms used it would be easy to add some references within the wiki-system.

==== Content aspects ====
* The subject of leadership styles and the different focus areas of a leader is very interesting, but I think the article would be more interesting for a practitioner if it elaborated the content of the standards and made a more clear comparison between them or just focused on one standard.
* The relation to a specific project, program or portfolio management topic is a bit hard to see, since the article contains more of an overview than it deals with a specific problem/method.
* The article is very short. The remaining 2000 words could be put into good use focusing on a specific leadership style or comparing the content of the different standards as mentioned earlier.
* The flow through the article so far is logical.
* References should be given to the sources used.
* It is hard to judge the quality of the sources used for the article as they are not directly given. From the different standards mentioned in the text, it seems that the sources are trustworthy and of high quality.
* The article does not contain an annotated bibliography of any source.
* The article does not link to other relevant pages in the APPPM wiki.
* The “introduction” is very objective and does not leave the reader in doubt of that statements are substantiated by literature and not “own opinion”. The “limitations” part however seems more like “own opinion” statements, but this is not given anywhere.
* The article seems to be free of “copy & paste” plagiarism since the sources of the different statements are mentioned in the text, but as there are no actual references (I can see that an attempt to use citation has been made but not completed) I cannot be sure.

Talk:Leadership styles

2015-09-22T19:13:02Z

S141926:

Anna: Hi I like the idea, however, I'm afraid that it doesn't really fit into either one of the two article types. This is not really a method, but you could easily choose a method within the topic of leadership.

== Review of S141926, Reviewer 1 ==
==== General formal aspects ====
* Overall the writing is clear and precise with the use of appropriate technical words that make the article look academic and professional. However, I found some words mistranslated from Danish, like “Personel” and minor grammatical issues like “more narrow” instead of narrower.
* In my opinion, I think it would make the article easier to be read if you added more full stops and you split the, under my point of view, too long paragraphs. I liked the paragraph where you make questions and answer them. However, I think that this part would be clearer in bullet points (under my point of view).
* As I mention in the following section, the limitations/solutions part could be nicely shown in a format table to make the article more readable as well as adding some graphics to illustrate the methodology.
* I suggest you to review the Wikipedia formatting, I can see some references and links not well defined or linked.

==== Review of the content ====
* Regarding the Introduction part I think that gives a too general conclusion and does not focus enough to the main topic of the article, which is Leadership styles. Under my point of view, it is too focused on Standards and Managers competences and I am missing some more specific information about leadership in general.
* I think it would also improve your article to get more into detail on the different skills required for a project manager under different scenarios.
* Apart from the fact that as I said I think there is some information missing that would make the article more understandable, I think that you would also had to add some more writing in order to fulfil the requirements regarding length.
* I would advise to review the requirements of the article type and adding a method regarding leadership and define the uses/limitations of this particular method.
* I liked the limitations and problems pointed out when saying that a manager does not have to possess technical skills in the project he/she manages and all problems that come up due to this matter. I found the information given interesting but it might be a good idea to type those problems/solutions in a tabular format or in separated paragraphs.
* I think it would be a good idea to add some more conclusions. However, I found the ones you mentioned relevant and a good summary of the above explained.
* Remember also to add the references part, I am afraid it is compulsory :) And maybe a Table of contents at the beginning.

== Review given by StephSalling, review3 ==
As far as I can tell, this article is not done yet, so I will possibly point out some things you were already planning to change or add.

==== Formal aspects ====
* The different parts in this “method” study are a bit hard to tell apart. The “big idea” is combined with the “application”, but none of them are really adequately described. From my point of view, the “limitations” part in the article is the best part, but it should be substantiated with some literature.
* The grammar, spelling and punctuation in the “introduction” and “conclusion” are generally good: There are only a few singular/plural mistakes. It seems that the “limitations” part has not been proofread as thoroughly as the other sections.
* Even though there are not many fill words in the sentences (which is very good), some of the sentences are a bit long and hard to follow. Maybe some bullet points illustrating the content of the different standards would help make it easier to read. - Or simply dividing the text into more paragraphs.
* Some illustrations of the content of the different standards could be helpful.
* With the many different standards mentioned and technical terms used it would be easy to add some references within the wiki-system.

==== Content aspects ====
* The subject of leadership styles and the different focus areas of a leader is very interesting, but I think the article would be more interesting for a practitioner if it elaborated the content of the standards and made a more clear comparison between them or just focused on one standard.
* The relation to a specific project, program or portfolio management topic is a bit hard to see, since the article contains more of an overview than it deals with a specific problem/method.
* The article is very short. The remaining 2000 words could be put into good use focusing on a specific leadership style or comparing the content of the different standards as mentioned earlier.
* The flow through the article so far is logical.
* References should be given to the sources used.
* It is hard to judge the quality of the sources used for the article as they are not directly given. From the different standards mentioned in the text, it seems that the sources are trustworthy and of high quality.
* The article does not contain an annotated bibliography of any source.
* The article does not link to other relevant pages in the APPPM wiki.
* The “introduction” is very objective and does not leave the reader in doubt of that statements are substantiated by literature and not “own opinion”. The “limitations” part however seems more like “own opinion” statements, but this is not given anywhere.
* The article seems to be free of “copy & paste” plagiarism since the sources of the different statements are mentioned in the text, but as there are no actual references (I can see that an attempt to use citation has been made but not completed) I cannot be sure.

Articles Fall Term 2015

2015-09-22T11:25:15Z

S141926:

Please complete this table with your name, user name and the title of your article.

To create more lines in the table click '''Edit''' and use the following code to create more lines in the table and replace the example text with your own information:

<pre style="white-space: pre-wrap;
white-space: -moz-pre-wrap;
white-space: -pre-wrap;
white-space: -o-pre-wrap;
word-wrap: break-word;">
|Group Number
|Last Name
|First Name
|Username
|Link to Article
|-

Create a direct link by making square brackets around the title [[Title]] (Case sensitive)

The straight lines ( | ) create columns and the straight line with a dash ( |- ) creates a new row in the table.
( |} ) is only used at the very end to finish the coding for the table.
</pre>

=Overview of 2015 Wiki Articles=

{| class="wikitable sortable"
|+Fall 2015 Wiki Articles
|-
!Group Number
!Last Name
!First Name
!User Name
!Link to article
|-
|Group 1
|Nguyen
|Michael
|Michaelnguyendtu
|[[Leading an offshore team]]
|-
|Group 12
|Gkatzalas
|Nikolaos
|s141569
|[[The Gantt chart and the usage nowadays]]
|-
|Group 6
|Lymperis
|Konstantinos
|s142330
|[[Risk Management in Oil and Gas Industry]]
|-
|Group 3
|Filis
|Charalampos
|Ch.filis
|[[Project Risk Management and Project Risk Management Processes]]
|-
|Group 11
|Larsen
|Leonora
|s112910
|[[Gantt Charts as a Tool for Project Management]]
|-
|Group 10
|Sala Vilar
|Lluís Ròmul
|s141586
|[[Portfolio Management in a Startup]]
|-
|Group 14
|Pitsavas
|Konstantinos
|Konspits
|[[Modularisation: A modern process for project management]]
|-
|Group 2
|Kampianakis
|Andreas
|s150912
|[[Financial Portfolio Optimization Methods]]'''
|-
|Group 13
|Penzes
|Balint
|s141943
|[[Product development and portfolio management processes at LEGO]]
|-
|Group 6
|Hozmache
|Mihaela
|s146898
|[[PRINCE2 - For successful Project Management]]'''
|-
|Group 14
|Le Corre
|Damien
|Damien
|[[Game theory in project management]]'''
|-
|Group 14
|Bertrand
|Fabien
|150477
|[[Multi project management]]'''
|-
|Group 9
|Cassel
|Sara
|Sarac
|[[The benefits of systems engineering]]'''
|-
|Group 13
|Sergi
|Gibaja Musachs
|S141926
|[[Manage Extreme Projects with Rapid Methodology]]'''
|-
|Group 14
|Poza
|María
|s150793
|[[Integrated Cost and Schedule Control]]'''
|-
|Group 6
|Kulikova
|Nataliia
|s140767
|[[SCRUM Method]]
|-
|Group 4
|Pekala
|Adam
|Adam.pekala
|[[Critical Path Method in Construction Industry]]
|-
|Group 10
|Garnotel
|Gaëtan
|gaetangarnotel
|[[V-Model]]
|-
|Group 4
|Ghanizada
|Naweed
|S103745
|[[PRINCE2, A Project Management Methodology]]
|-
|Group 1
|Jacobsen
|Martin
|MistaJacob
|[[Mindfulness and Cognitive Biases in Project Management]]
|-
|Group 6
|Ferraresi
|Fabrizio
|S150905
|[[Projects in Controlled Environments, a process-based approach for project management]]
|-
|Group 5
|Tanghus
|Bjarke
|S113815
|[[Location Based Scheduling]]
|-
|Group 9
|Højgaard Hindhede
|Daniel
|S143352
|[[Construction modularization from a lean perspective]]
|-
|Group 10
|Gayot
|Charles-Henri
|s141074
|[[Responsibility Assignment Matrix (RACI Matrix)]]
|-
|Group 12
|Thorp Sørensen
|Anders
|s103183
|[[The Gantt Chart]]
|-
|Group 3
|Makris
|Dimitrios
|Dimak
|[[Benchmarking in Project Management]]
|-
|Group 7
|Greiling
|Lea
|Lea
|[[Lean in Project Management]]
|-
|Group 8
|Latorre Duque
|Ana
|Ana
| [[Modularity and Black-Boxing]]
|-
|Group 7
|Almanzi
|Stefano
|S141530
|[[ Work Breakdown Structure (WBS)]]
|-
|Group 12
|Montagner
|Giacomo
|S150821
|[[Scrum Methodology in Agile Software Development]]
|-
|Group 14
|Ruiz Muñoz
|Gustavo Adolfo
|S121408
| [[Lean 6 Sigma in project management]]
|-
|Group 3
|Kalmus
|Thomas
|S141938
| [[Program evaluation and review technique (PERT) ]]
|-
|Group 12
|Gudmundsson
|Arnar Gauti
|S141543
|[[Management of risk]]
|-
|Group 5
|Jacobsen
|Ian Thobias
|S113735
|[[Story Points Estimation]]
|-
|Group 11
|Boesgaard
|Katrine
|KB1991
|[[Gantt Chart]]
|-
|Group 5
|Sorth-Olsen
|Rasmus
|Sorth90
|[[Lean as a project management tool]]
|-
|Group 13
|Salling
|Stephanie
|StephSalling
|[[E. Pihl & Søn A/S from a management perspective]]
|-
|Group 6
|Ruina
|Jessica Linda
|Jejenji
|[[Scheduling techniques in Project Management]]
|-
|Group 4
|Gjerstrup
|Jacob
|s113440
|[[Fault tree analysis]]
|-
|Group 11
|Lynge
|Jane
|s997303
|[[Theory of Constraint]]
|-
|Group 8
|Palmerini
|Alessandro
|alex161
|[[Effective Communication in Project Management]]
|-
|Group 2
|Tvedt
|Ida Marie
|IMT
|[[Risk Profile in Turnkey Projects]]
|-
|Group 2
|Søndenaa
|Mathilde Hanssen
|s150621
|[[Critical chain project management (CCPM)]]
|-
|Group 9
|Helassalo
|Antti
|s141506
|[[Development phase of idea to project]]
|-
|Group 9
|Thorning-Schmidt
|Nanna
|Nannats
|[[Earned Value Management]]
|-
|Group 10
|Bureika
|Edvinas
|s141931
|[[Communication in Project Management]]
|-
|Group 1
|Rasmussen
|Marie-Louise
|DI2009
|[[Cross cultural teamwork]]
|-
|Group
|Lara Hoces
|Fernando
|s131882
|[[The Oticon Case: the Spaghetti organisation]]
|-
|Group 13
|Christos
|Stamatis
|S145170
|[[Olympic Games London 2012: When the client strives for innovation (The London model)]]'''
|-
|Group 5
|Moe
|Elizabeth Lindhard
|113129
|[[Contracting as a PM]]
|-
|Group 3
|Lessis
|Vasileios
|lessisv
|[[Rational Unified Process (RUP)]]
|-
|Group 8
|Klibo Buur
|Christian
|Buurbuur
|[[Project Execution Model (PEM)]]
|-
|Group 8
|Bachmann
|Thomas
|s117318
|[[Lean Tools in Project Management]]
|-
|Group 11
|Vilar Bustos
|Alberto
|s142581
|[[Minimizing Risk and Uncertainties in Construction Projects]]
|-
|Group 1
|Trap Wiegandt
|Sissel
|s112195
|[[The Critical Path Method (CPM)]]
|-
|Group 2
|Christensen
|Britt Marie Lekven
|brittmch
|[[Lean in building and construction industry]]
|-
|Group 5
|Vestergaard Andersen
|Andreas
|AndreasAndersen
|[[Management of Project Change ]]
|-
|Group 7
|Ann-Elise
|Gustavsen
|Alise
|[[Stakeholder Analysis and Matrices ]]
|-
|Group 2
|Krogh
|Daniel
|DanielKrogh
|[[Managing Uncertainty and Risk on the Project]]
|-
|Group 7
|Fabio
|Labrini
|s142911
|[[Critical Chain Project Management to cope with uncertainty]]
|-
|Group 1
|Viig
|Oliver Johannes
|s102935
|[[BIM as a project management tool on construction projects]]
|-
|Group 8
|Federico
|Sbernini
|s141573
|[[The Failure Mode and effects analysis (FMEA) in product development projects]]
|-
|Group 12
|Augustin
|Bouet
|s142823
|[[Metra Potential Method]]
|-
|Group 7
|Eva Schultz
|Hansen
|s112960
|[[A method to analyze visualizations in project management as boundary objects]]
|-
|Group 13
|Otiv
|Peter
|s145166
|[[Project Financing Initiative]]
|-
|Group 4
|Juhasz
|Bianka Zsuzsanna
|Biankajuh
|[[Changing conversations based on the Stacey matrix]]
|-
|Group 3
|Rodrigues
|Rafael
|s150931
|[[Six Sigma and PMBOK]]
|-
|Group 9
|Søren
|Thomsen
|s140046
|[[Organisational resilience with mindfulness]]
|-
|Group 8
|Schrøder
|Niklas
|Faker
|[[Theory of Constraints]]
|-
|Group 11
|Herreros
|Maria
|s142597
|[[Early warning signals in project management]]
|-
|Group 3
|Larsen
|Martin T
|s103128
|[[Risk Identification]]
|-
|Group 9
|Hoier
|Lasse Rasmus
|Lassehoier87
|[[Application of Antifragility in Project Management]]
|-
|Group 4
|Shapel
|Sarah Groot
|s152093
|[[Leadership styles]]
|-
|Group 4
|Hammer
|Jonas
|s113665
|[[The best milestone plan is simple but with depths!]]
|-
|Group 2
|Flataukan
|Camilla
|s150801
|[[Risk Profile in General Contracting]]
|-
|Group 10
|Marazaki
|Ilektra
|s142899
|[[Portfolio Management and complexity in organizations]]
|-

|}

Manage Extreme Projects with Rapid Methodology

2015-09-22T11:23:42Z

S141926: Created page with "== Background == Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional m..."

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects. [[File:drawing.jpg |thumb||right||300px|Approaches representation]]
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==
<references />

Rapid Application Development in Extreme Project Management

2015-09-21T21:45:16Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects. [[File:drawing.jpg |thumb||right||300px|Approaches representation]]
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project and the employees will be given training on them.

== References ==
<references />

Rapid Application Development in Extreme Project Management

2015-09-21T21:43:25Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects. [[File:drawing.jpg |thumb||right||300px|Approaches representation]]
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

The success of combining Extreme Project Management and Rapid Methods depends on a number of factors, but if most of the following characteristics apply to the project it will surely have been a good decision.

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies must help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project. Frequent feedback is a must during all the project especially due to the constantly changing requirements that imply an extreme project.

== References ==
<references />

Rapid Application Development in Extreme Project Management

2015-09-21T21:37:37Z

S141926:

== Background ==
Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects. [[File:drawing.jpg |thumb||right||300px|Approaches representation]]
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.

==== The four main factors, their problems and how to overcome them ====
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done. <ref name=mc/>
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

==Discussion==

To success managing an extreme project with Rapid Methodology, it is vital that the following characteristics apply:

*It is likely that the requirements will change during the project or that unexpected events occur that make the manager have to reschedule. In the kind of projects where the desired result is very clear but how to reach it is unclear as well as in projects where innovation is an everyday task and new methods and tools that can help the project are being developed as the project goes.

*Meetings among stakeholders and managers can be carried out regularly during all the stages of the project. In the early state it is critical to fully agree and discuss all the details and requirements of the project to start in the best direction possible while later at the project if some unexpected event comes up, disagreement could happen and it becomes very important that the implied parties can be gathered together quickly and are willing to discuss in a collaborative manner.

*Appropriate managers for this uncertain atmosphere available. Due to the high trial-error it is important that the managers in charge of this sort of project are able to keep the employees motivated and ready for facing some sort of disappointments throughout the project. These managers must also possess innovation and quick reaction skills which make them effective and productive managers.

*Companies must help growing the knowledge of the employees and keep them updated with the new tools. The selection of these tools will be an important factor in terms of efficiency of the project. Frequent feedback is a must during all the project especially due to the constantly changing requirements that imply an extreme project.

== References ==
<references />

Rapid Application Development in Extreme Project Management

2015-09-21T18:33:43Z

S141926:

Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects. [[File:drawing.jpg |thumb||right||300px|Approaches representation]]
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methodology==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===Use of Rapid Methodology to manage Extreme Projects ===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.
Main factors and common issues associated to rapid methods.
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"|
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| How to avoid them
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done.
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

== References ==
<references />

Rapid Application Development in Extreme Project Management

2015-09-21T16:44:32Z

S141926: /* Traditional approach overview */

Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>.So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects. [[File:drawing.jpg |thumb||right||300px|Approaches representation]]
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methods==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===How the application of rapid models benefit extreme projects===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.
Main factors and common issues associated to rapid methods.
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"| Factor
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| Recommendations
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done.
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

== References ==
<references />

Rapid Application Development in Extreme Project Management

2015-09-21T16:41:42Z

S141926:

Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>. Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref>. So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects. [[File:drawing.jpg |thumb||right||300px|Approaches representation]]
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

==Managing extreme projects with rapid methods==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===How the application of rapid models benefit extreme projects===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.
Main factors and common issues associated to rapid methods.
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"| Factor
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| Recommendations
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done.
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

== References ==
<references />

File:Small.JPG

2015-09-21T16:34:23Z

S141926:

Rapid Application Development in Extreme Project Management

2015-09-21T16:22:10Z

S141926:

Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out.<ref name=wyssecond> "Wysocki, R. K. (2010). Adaptative Project Framework. Managing complexity in the face of uncertainty. Pearson Eduation, Inc." </ref>. Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref>. So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: <ref name=wys> "Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme. Indiniapolis: Wiley Publishing." </ref> <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

[[File:drawing.jpg]]
==Managing extreme projects with rapid methods==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===How the application of rapid models benefit extreme projects===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.
Main factors and common issues associated to rapid methods.
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: <ref name=mc> "McConell, S. (1996). Rapid development: Taming wild software schedules. Redmond, Washington: Microsoft Press." </ref> People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"| Factor
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| Recommendations
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done.
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

== References ==
<references />

File:Snipping.jpg

2015-09-21T16:21:28Z

S141926:

File:Graph.jpg

2015-09-21T16:20:25Z

S141926:

File:Drawing.jpg

2015-09-21T16:17:48Z

S141926:

Rapid Application Development in Extreme Project Management

2015-09-21T16:00:14Z

S141926:

Extreme Project Management is a modern approach to [https://en.wikipedia.org/wiki/Project_management Project Management] that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the [https://en.wikipedia.org/wiki/Waterfall_model Waterfall Model], where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses the concept of Rapid Methods based on [https://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development (RAD)] which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Methodology.

__TOC__

== Traditional approach overview ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly <ref name=decar>''DeCarlo, D. (2004). eXtreme Project Management. San Francisco, CA, US: Jossey-Bass. A Wiley Imprint.'' </ref>

The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out. (Wysocki, Adaptative Project Framework. Managing complexity in the face of uncertainty, 2010) So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. <ref name=kli> "Kliem, R. (1997). Project Management Methodology: a practical quide for the next millenium. New York ,NY, US: Marcel Dekker." </ref>. Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” <ref name=decar /> , characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: (Wysocki, 2010) <nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.<ref name=decar />

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that. <ref name=decar />

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

FIGURE HERE

==Managing extreme projects with rapid methods==

===Overview===
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. <ref name=jak>"Jakobsen, C. M. (2001). XPM from idea to realization. Synopsis" </ref> . This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

===How the application of rapid models benefit extreme projects===
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.
Main factors and common issues associated to rapid methods.
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: (McConell, 1996) People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"| Factor
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| Recommendations
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven <ref name="oth”> " DeMarco, T. a. (1999). Peopleware: Productive projects and teams. New York, US: Dorset House Publishing."</ref> that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done.
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

== References ==
<references />

Rapid Application Development in Extreme Project Management

2015-09-21T14:50:44Z

S141926:

== Abstract ==
Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the Waterfall Model, where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses a different concept based on Rapid Application Development (RAD) called Rapid Planning which focuses more on development rather than planning.

In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Planning.

__TOC__

== Overview of Project Management ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly (DeCarlo, 2004).
The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable (Kliem, 1997). By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.

The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out. (Wysocki, Adaptative Project Framework. Managing complexity in the face of uncertainty, 2010) So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

===Change of mindset===

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. (Kliem, 1997). Generally speaking, the basis of the traditional approach is managing the known.

The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” (DeCarlo, 2004), characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.

Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: (Wysocki, 2010)
<nowiki> “</nowiki>''Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed'' <nowiki> “</nowiki>

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that.

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

FIGURE HERE

=Managing extreme projects with rapid methods=

==Overview==
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. (Jakobsen, 2001) This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

==How the application of rapid models benefit extreme projects==
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.
Main factors and common issues associated to rapid methods.
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: (McConell, 1996) People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"| Factor
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| Recommendations
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven (DeMarco, 1999) that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done.
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

== References ==

Rapid Application Development in Extreme Project Management

2015-09-21T14:43:30Z

S141926:

== Abstract ==
Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.
Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.
While the traditional approaches are characterized for a sequential design process known as the Waterfall Model, where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses a different concept based on Rapid Application Development (RAD) called Rapid Planning which focuses more on development rather than planning.
In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Planning.
__TOC__

== Overview of Project Management ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly (DeCarlo, 2004).
The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable (Kliem, 1997). By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.
The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out. (Wysocki, Adaptative Project Framework. Managing complexity in the face of uncertainty, 2010) So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

===Change of mindset===

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. (Kliem, 1997). Generally speaking, the basis of the traditional approach is managing the known.
The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” (DeCarlo, 2004), characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.
Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: (Wysocki, 2010)
“Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed”

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that.

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

FIGURE HERE

=MANAGING EXTREME PROJECTS WITH RAPID PLANNING=

==Overview==
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. (Jakobsen, 2001) This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

==How the application of rapid models benefit extreme projects==
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.
Main factors and common issues associated to rapid methods.
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: (McConell, 1996) People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"| Factor
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| Recommendations
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven (DeMarco, 1999) that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done.
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

== References ==

Rapid Application Development in Extreme Project Management

2015-09-21T14:42:44Z

S141926:

== Abstract ==
Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.
Those arisen problems during the execution of the project are one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.
While the traditional approaches are characterized for a sequential design process known as the Waterfall Model, where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses a different concept based on Rapid Application Development (RAD) called Rapid Planning which focuses more on development rather than planning.
In the present article the Extreme Project Management will be described and its main differences with the traditional approach highlighted. It will follow how to deal with XPM by means of Rapid Planning.
__TOC__

=== XPM vs. Traditional approach ===
=== When should XPM be used? ===
=== Change of mentality of the users ===
== Rapid Application Development Concept ==
=== Definition ===
=== Application of RAD on XPM ===
=== Limitations ===
== References ==

== Overview of Project Management ==

The way that project managers deal with projects nowadays has not only changed totally during the last decades but also irreversibly (DeCarlo, 2004).
The traditional approach was characterized for being rather rigid and structured under the assumption that the future was predictable (Kliem, 1997). By studying the project, with deep analysis of risks and scheduling a proper forecast with a good degree of confidence was reachable. This approach was highly focused on efficiency, e.g. minimizing cost and time was vital. Another aspect of interest was finding a good balance among cost, schedule and quality. Most of the times it was considered it to be a zero-sum game where from achieving one of them project managers often had to sacrifice one, or two, of the rest.
The traditional project management life cycle is defined by five phases: Definition, Detailed Plan, Launch plan, Monitoring Progress and Closing out. (Wysocki, Adaptative Project Framework. Managing complexity in the face of uncertainty, 2010) So the project manager is given a clear statement from the customer of what is wanted and when as well as how much is the customer willing to pay for it so there is no much room for changes. It is also expected that the customer will not change his mind throughout the process and that no external factors will have a big impact on it.

== Extreme Project Management ==

===Change of mindset===

In the Traditional approach there was generally rejection of a change throughout the project. This was viewed as an anomaly, so even though it was not acceptable had to be managed somehow and here is where the problems rose. The inflexibility surrounding this approach often led to create an uncomfortable atmosphere on the team where the main attention was put on meeting deadlines regardless the consequences. (Kliem, 1997). Generally speaking, the basis of the traditional approach is managing the known.
The opposite definition applies for Extreme Project Management, where “Extreme Project Managers are required to manage the unknown” (DeCarlo, 2004), characterizing this sort of projects for being besides unpredictable also messy and chaotic where innovation is crucial due to the constantly changing environment. Those changes are not only a result of the uncertainty surrounding the project itself but also due to external factors such as new technology, changes in regulations, requirements, moves of the competitors, unexpected results during testing, political decisions that might affect, economic crisis, change in the customer needs and so on and so forth.
Professor Robert K. Wysocki refers to this change of attitude from the traditional approach giving the following suggestion that reflects the above explained: (Wysocki, 2010)
“Forget about a formal change-management process in which the change request is documented, reviewed by the portfolio committee (…) Extreme projects can’t wait that long. Another approach is needed”

===Extreme projects are demanding===
They require a high degree of speed and innovation due to the constantly changing requirements. The former is important due to the fact that if one spends too much time studying the project and considering what next step to take by the time the plan is ready it might be irrelevant and not useful anymore. While the latter, innovation, is probably what extreme management is all about. It is what makes the difference and what makes a project manager to be effective and productive. One cannot shorten the project time line in half by working twice as hard but working efficiently innovating for each of the single and unique projects.
Extreme projects require discovering what is truly necessary for the plan to proceed and succeed by a sort of trial-error process, day by day. Like Doug DeCarlo defines extreme project; “An extreme project is complex, self-correcting venture in search of a desirable result”.

===Dealing with high levels of uncertainty===
The fact that these projects imply a lot of trial-error, the project changes direction several times or it can even end up being cancelled but several new projects based on the learnings from it might start cause a lot of fears on the project managers. For all this reasons is important for the managers to keep motivation and ambition. They should be aware before starting that extreme projects are extremely challenging and that the idea that one has in mind before starting the project might be completely different from the final result.
It is therefore required that the extreme project managers are adaptive, agile, sustain commitment and willing to carry with the everyday tasks that extreme project concerns, as Doug DeCarlo says: “To succeed means to plan, deplan and replan weekly, even daily.” so they need to be ready for that.

It has been previously mentioned that extreme projects are messy and chaotic and this is not anybody’s fault, it is how it is. Things happen while plans are being made without anything one can do but responding to it as good as possible. For this reason an Extreme Project does not follow the Traditional Project Model which is based on the waterfall model, a sequential process in which progress is shown as a flowing steadily downwards through different phases that lead to a well-defined goal with a proven path to get to the objective. Instead, XPM even though that has a clear goal it has a more undefined path which is said not to be straight but redirected every time that something new comes up, which is frequent. An example used in a number of management books is that extreme managing is shooting a gun towards a goal and throughout the process the “bullet” is redirected several times.

FIGURE HERE

=MANAGING EXTREME PROJECTS WITH RAPID PLANNING=

==Overview==
Rapid planning is a project managing method used for developing project plans which is based on the Rapid Application Development (RAD) model, widely used as a software development methodology that uses minimal planning in order to obtain rapid working model to start with.
The fact that there is no detailed preplanning makes it easier to include the changes that we have been talking about that come up during the project.
It focuses on gathering all the requirements for the project itself at the very beginning. The project manager must identify the stakeholders and along with the team members undertake the planning process in an open and collaborative manner. (Jakobsen, 2001) This process implies that the stakeholders that might be in disagreement are together and open for discussion. It is a key point getting the stakeholders on agreement on the scope, goals and procedure which might be challenging task sometimes.

==How the application of rapid models benefit extreme projects==
The method is based on meeting the requirements of the desired result involving the stakeholders from the start and focusing all the way on their need managing risks in order to avoid setbacks. The approach focuses on adjusting requirements as the user earns knowledge as the project progresses which makes this method especially interesting for extreme projects. It is also a very flexible method so it is adapted to the changes easily, which is not the case for traditional approaches where the requirements are rigorously defined from the start.
In order to fully benefit from this methods it is vital to get a deep understanding of the client’s needs and all the implied parties to avoid misunderstanding that can lead to setbacks and disputes. Frequent checking and updated feedback of the process to let the client know the current situation and redirect as soon as possible if the process is getting out of the scope.
Main factors and common issues associated to rapid methods.
There are a number of factors associated to Rapid methods that will lead to the success or failure of the project. Those factors were summarized to four by the Rapid Development and Project Management expert Steve McConell: (McConell, 1996) People, Process, Product and Technology. The mistakes associated to those factors will be the trigger for slow development and likely failure, as it will be discussed after defining the four factors.

{| class="wikitable" style="text-align:left;"
|- style="vertical-align:top;"
|-
! scope="col"| Factor
! scope="col"| Overview
! scope="col"| Common issues
! scope="col"| Recommendations
|-
|- style="vertical-align:top;"
! scope="row"| PEOPLE
|Clearly, employees taking part in the project play an important role in the success of the project, basically they are thee one in charge of transforming the knowledge into products or whatever is the desired result. Therefore companies have to find ways to increase the skills, knowledge and level of proficiency of their employees in order to be competitive and also try to maintain them happy so they continue growing the company’s potential
| It has been proven (DeMarco, 1999) that issues concerning people have the highest impact on both productivity and quality. Some common scenarios are project managers with highly technical backgrounds with poor people management knowledge leading to a high employee turnover. This turnover along with contracting new people once the project is started pretending to meet an unlikely deadline cause a decrease in productivity as well as frustration on all people involved
| Provide guidance to working with teams and enhancing group dynamics to all the employees as well as train project managers to effectively manage their team members.
|-
|- style="vertical-align:top;"
! scope="row"| PROCESS
| All parties implied in the process should be required to fully get an understanding of not only customer’s requirements but also the needs as well as keeping the customer involved throughout the process.
Improving the process the amount of rework will be reduced which leads to increased control of costs as well as the ability to make risk management decisions based on real data.
| Poorly defined procedures, guidelines and plans are usually the cause of slow development causing a waste of time of the employees. Also, over optimistic schedules increasing the risk of failure as well as poorly defined or changing standards of quality.
| It is critical to identify, address and eliminate the sources of risk before they threat the project so a proper risk management analysis must be done.
In order to fulfil the aimed standards of quality, Quality Assurance fundamentals with quality plans must be considered to ensure that the project is developed according to the defined processes and it also provides feedback about how effective the processes which can be a very useful information for the project managers.
|-
|- style="vertical-align:top;"
! scope="row"| PRODUCT
| A clear idea of product’s size and characteristics is a must for schedule shortening. Considering alternatives to production like product development in stages can reduce considerably the schedule for instance.
| As it has been said, product/project size is one of the largest contributors to the schedule, so all the managing aspects concerning the size of the project are critical
| Once again, working close and frequent feedback with the customers is vital and all the parties need to be aware that when requirements are modified this effects somehow the schedule and so it increases the risk of missing the deadline. . Another relevant matter is the need of specify an acceptance criteria with the customer so if meeting the requirements agreed with the client it is ensured that the quality is important.
|-
|- style="vertical-align:top;"
! scope="row"| TECHNOLOGY
| Definitively the effectiveness of the tools is crucial here. Choosing the appropriate tools and efficient implementation strategy is the key. It is also a constantly changing factor therefore one needs to be prepared for implementing new tools and make them to be beneficial for the project.
| Technology may cause problems for either overestimating the potential or for too high expectations. Both of them may be due to a lack of understanding of the productivity of a new tool implemented on the project. Also, introducing or switching tools in the middle of a project may be counter-productive and increase the schedule delay due to the fact that users need to invest some time with the new technology before being completely proficient with it.
| Software tools and other technology are constantly changing so it might be difficult to totally avoid the problems related to technology, especially in long projects where the implementation of a new tool in the medium of the project could be very beneficial at long term. It is therefore advisable to incorporate additional time for training the employees in the new technology
|}

Rapid Application Development in Extreme Project Management

2015-09-17T09:02:27Z

S141926:

Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project is one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the Waterfall Model, where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses a different concept based on Rapid Application Development (RAD) which focuses more on development rather than planning.

In the present article the Extreme Project Management will be carefully analysed as well as the implementation of RAD on this method.

__TOC__

== Overview of Extreme Project Management ==
=== XPM vs. Traditional approach ===
=== When should XPM be used? ===
=== Change of mentality of the users ===
== Rapid Application Development Concept ==
=== Definition ===
=== Application of RAD on XPM ===
=== Limitations ===
== References ==

Rapid Application Development in Extreme Project Management

2015-09-10T09:46:50Z

S141926:

Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project is one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the Waterfall Model, where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses a different concept based on Rapid Application Development (RAD) which focuses more on development rather than planning.

In the present article the Extreme Project Management will be carefully analysed as well as the implementation of RAD on this method.

__TOC__

== Extreme Project Management ==
=== Definition ===
=== XPM vs. Traditional approach ===
=== When should XPM be used? ===
=== Change of mentality of the users ===
== Rapid Application Development Concept ==
=== Definition ===
=== Implementation of RAD on XPM ===

Rapid Application Development in Extreme Project Management

2015-09-10T09:46:40Z

S141926:

Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project is one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the Waterfall Model, where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses a different concept based on Rapid Application Development (RAD) which focuses more on development rather than planning.

In the present article the Extreme Project Management will be carefully analysed as well as the implementation of RAD on this method.

__TOC__

== Extreme Project Management ==
=== Definition ===
=== XPM vs. Traditional approach ===
=== When should XPM be used? ===
=== Change of mentality of the users ===
== Rapid Application Development Concept ==
=== Definition ===
=== Implementation of RAD on XPM ===

Articles Fall Term 2015

2015-09-10T09:46:13Z

S141926:

Rapid Application Development in Extreme Project Management

2015-09-10T09:43:55Z

S141926:

Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project is one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the Waterfall Model, where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses a different concept based on Rapid Application Development (RAD) which focuses more on development rather than planning.
In the present article the Extreme Project Management will be carefully analysed as well as the implementation of RAD on this method.

__TOC__

== Extreme Project Management ==
=== Definition ===
=== XPM vs. Traditional approach ===
=== When should XPM be used? ===
=== Change of mentality of the users ===
== Rapid Application Development Concept ==
=== Definition ===
=== Implementation of RAD on XPM ===

Rapid Application Development in Extreme Project Management

2015-09-10T09:43:26Z

S141926: Created page with "Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements througho..."

Extreme Project Management is a modern approach to project management that differs from other traditional methods for its ability to have new or changing requirements throughout the project. This has become especially interesting in today’s projects, where, they tend to require changes very frequently, due to a number of reasons such as Stakeholders changing their mind often, news about economical/environmental concerns, unexpected successes in the construction site and so on.

Those arisen problems during the execution of the project is one of the main challenges of the traditional project management methods. In the extreme approach, a project has no fixed project phases nor set of guidelines on how the activities should be executed but it adapts to the current situation and performs the best way possible. In contrast with the step-by-step workflow that characterizes the traditional model and its strict requirements the extreme method is more suitable to face the common unexpected changes that come up during today’s projects.

While the traditional approaches are characterized for a sequential design process known as the Waterfall Model, where the process takes the form of a linear-sequential model so each phase must be fully completed before the next one can start, the Extreme Project Management uses a different concept based on Rapid Application Development (RAD) which focuses more on development rather than planning.
In the present article the Extreme Project Management will be carefully analysed as well as the implementation of RAD on this method.

__TOC__

'''Table of contents'''
== Extreme Project Management ==
=== Definition ===
=== XPM vs. Traditional approach ===
=== When should XPM be used? ===
=== Change of mentality of the users ===
== Rapid Application Development Concept ==
=== Definition ===
=== Implementation of RAD on XPM ===

Articles Fall Term 2015

2015-09-08T20:28:42Z

S141926: /* Overview of 2015 Wiki Articles */

Articles Fall Term 2015

2015-09-08T20:24:46Z

S141926: