Note: English is my 2nd language

First I want to put the (for me) most important sentence that's associated with Project Management at the beginning:

Important is that a project can count as successful for the project manager, when all goals are met but it still can be a disaster for the client. This is often the case when the projects requirements are fulfilled, but they weren’t defined right at the beginning of the project (project kick-off) (De Wit, 1988).

Note 2: This is a paper that I wrote for a university course in summer 2017, I now decided that this will be my first steemit post, many willl follow.

Introduction

Since 2010 figures of the Project Management Institute shows that the success of IT-Projects is finally rising, after years of stagnating and even falling success rates (chaos summary 2010.pdf, n.d.). Still 1 of 4 projects is a failure, if you decline failure of trespassing the budget by more than 10 %. IT projects differ from normal engineering projects, they are characterized by high complexity and high failure rates (Silvera and Nieto, 2010, p.1). For everyone that has ever faced the issue of handling a team to achieve a good end product, especially in IT Projects, some problems will seem familiar. One big problem is that if project managers only focus to avoid problems on all costs and working with many guidelines and restricting conversations and different opinions, they are slowing down the innovative thinking of the project team, which can be a huge problem at the start of the project. Later on the people are just working on the project and do what they have to do and shouldn’t think too much about if it’s right what they are actually doing. In 1965 Bruce Tuckman invented a model, that is until today admitted by science and was completed in 1977. It’s general meaning that a team has 5 stages of development: Forming, Storming, Norming, Performing, Adjourning (BruceTuckman_Team_Development_Model.pdf, n.d.). There it is shown that a team nearly every time has 5 stages. The real work starts at the beginning for the Project Manager, for the team it starts with the norming and is reaching it’s peak in the performing phase (see Figure 1).

![getting-a-new-agile-team-up-and-running_-part-1-the-kick_off-workshop-group_stages_diagram.jpg]

Figure 1: The 5 stages of group development

Complexity in IT-Projects

In figure 2 there is noticeable that from 2002 till 2008 the failure of IT-Projects was growing

Figure 2: Chaos Summary 2000-2008

over the years from only 15 % to 24 %, which means that nearly 1 of 4 projects is called a failure and both sides, customer and the executive company are not happy with the outcome. A project is here called a success if it is within a cost range of 20 % budget margin (ten percent under till 10 percent over budget). When comparing these numbers to figure 2, it is seen that in 2015 only (almost) 1 of 5 projects failed.

Figure 3: Chaos Report 2011-2015

There is really a need to understand why IT-Projects have still such a high failure rate and how to try to reduce that. The Chaos Report of 2015 indicates, according to www.infoq.com (Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch, 2017), that projects tend to be more successful the smaller they are. So one way to increase the number of successful projects could be to split bigger projects into smaller parts (it’s already done by almost every company), which is more and more done in the last decades. This requires a lot of preparation work and coordinating talent by the Project Manager in charge. From the programming side there are many more inventions that make working in bigger groups easier, one example is the git version control which was build to handle the coding of a few thousand developers for just one project (Loeliger and McCullough, 2012, chap.1, p.2). Git went live in the year 2005 (Loeliger and McCullough, 2012, chap.1, p.6) and helped the teams with code developing. It is used by every famous tech company, just to name a few: Google, Facebook, Microsoft, Twitter, LinkedIn, Linux, Gnome,… (Git, 2017).

In early stages you can still adjust the project way more easily than later on, later it is although much more expensive to adjust the project. As a consequence the first weeks of the project, called the project-kick-off is very important and determines and leads the whole path of the project.

Measurement of Complexity

The more tasks and stakeholders a project has and the longer the duration of a project is, the more complex it gets. The more men are applied to a project the higher is the contingence to lengthen and not shorten the project (Brooks, 1974, p.65). Project Complexity is always growing and is needed to assist the modern project management (Vidal, Marle and Bocquet, 2015, chap.Abstract). One big problem is that complexity is not the same for every person, relying on the personality and the experience and skills. There is a need to look at complexity with models, so it is possible to compare and relate to other products and find a common sense, this can also depend on the company, so that for e.g. Microsoft is way more skilled in managing software products, than Shell. It makes sense for every company to use model for their projects and store the data, so their data-pool is growing permanently and the prediction of complexity, resources, stakeholders,… that are needed for a project is getting permanently more exact.

Making Decisions

Using the Analytical Hierarchy Process (AHP), which was founded by Thomas Lorie Saaty to find solutions in complex situations it is likely to get a hint for the outcome of the project and what decision to make. Goals of the AHP are to support solutions in the team, to find the best solutions and to minimize the evaluated time, to understand the decision and to find inconsistencies in those. In Figure 4 there is an example of who to choose as the new company leader. The best decision in this case would be choosing Dick. Now let’s look in detail, how this outcome is produced. This model is explained in detail on Wikipedia (Analytic hierarchy process – leader example, 2016). The goal is to find a new leader, the criterias Experience, Education, charisma and age are defined as the most important ones. Then every possible leader is compared to every other possible leader in one category after another.

Figure 4: AHP

In Figure 5 there is the table of how many points can be given to each candidate compared to one of the others.

Figure 5: Scale of Pairwise Comparison

If now Tom and Dick go in the head to head comparison in Experience, and we rate Dick’s experience Moerate to strong hire than Tom’s, Dick will earn 4 points and Tom only 1, this is now entered into a matrix, where the correspondent of the higher number is shown as here ¼. This is shown in figure 6.

Figure 6: Experience

The priority is calculated by the AHP program, and shows in comparison to the others who is scoring the most points here, they are also rated the highest priority. This has to be done for every criteria. At the end there is also the need to calculate every criteria against every other criteria to see which is most important to the goal. The outcome is shown in figure 7. The best candidate in this case would be Dick.

Figure 7: Priority

To measure complexity it is obvious, as shown a bit above, it’s very hard to schedule and to rate things. Depending on the skills, experience, rates, nearly everything. Maybe another person would rate things totally different, resulting in a totally different outcome. Every person also has other references. This all leads to a growing complexity of it-projects. This is also the same for projects, and especially it-projects which are way harder to schedule. Programmers tend to always look first easy on a project and while programming they figure out that it is way more complicated than thought. Next there are some problems, which can occure, explained and looked at.

Occurring Problems

In this section are some of the major problems that can have a big impact on IT-Projects identified. In the sub chapters, there are some solutions explained as well as trying to dig deeper into the problem. According to Wallace, Keil and Rai there are three main risks: social subsystem risks, technical subsystem risks and project management risks (Wallace, Keil and Rai, 2004, p.302). This can be cut down to social risks, technical risks and project risks. These are (some) of the major problems that have been identified as major show stoppers and will be discussed in this paper:

1. Cost overruns
2. Lack of support of the top-management
3. Misunderstandings between customer and executive company
4. (Miss)management communication
5. (Obsolete) programming language

These problems can now be separated into the three groups as described by Wallace, Keil and Rai (2004, p.302):

1. Project Risks
   a. Misunderstandings between customer and executive company
   b. Cost overruns
2. Social Risks
   a. (Miss)management communication
   b. Lack of support of the top-management
3. Technical Risks
   a. Obsolete Programming language

Cost Overrun

One problem that is feared by the executive company on the one hand and by the customer on the other hand, surely depending on the signed contracts, is the cost overrun, which is likely normal for IT-Projects, but due to black swans one of six projects is having a cost overrun of 200% and this is driving the average way up (Flyvbjerg and Budzier, 2011). Software projects are well known for exceeding the budgets (Brenda Whittaker, 1999, p.Introduction). Therefore it is very important for the programming executive company to not calculate to tight, a well common practice is right now, mostly for bigger projects with many incalculabilities, to make a base price and to write some contingents into the contract, that can be called when needed. For bigger projects it’s often very hard to calculate the budget before the start. Often there are coming up problems and ideas from both the customer and the company while the process of thinking in detail about what the software can or should do. The executive company always has to explain to the customer, why they had to call this contingent. Here is a little example:

1. Designing the web-app 10.000 $
2. Setting up Front End 40.000 $
3. Setting up Back End 50.000 $
4. Additional Contingents
   a. Special Designing Wishes 5.000 $
   b. Free Contingent 25.000 $

So this example would have a base price of 100.000 $. If they are in the middle of the project and realize that there is way more to do in the backend then they could do for 50.000 $ they can talk to the customer and tell them that they would call up to 25.000 $ of the free contingent. This also or even more comes to mind, if the customer is always having new ideas and things that they want to have build in the software. Now the company could say: “No, we stick to the contract”, or say we can do this, if we call 10.000 $ of the additional contingent. This requires of course enough resources left to do this. All together you can say to this topic, that there must be trust between both companies. It although leads to increasing trust, because the news ideas of the customer can be fulfilled with a cost control. All told if you and your customer are new to each other you should focus more on sticking to a contract and to a fixed budget, cause on the way through the whole project there will always pop up problems that no one thought about before. Always stick to the contract, if there is the need to expand the project, set up a new contract after finishing the actual project.

Lack of support of the top-management

If the top-management (the highest that are involved in the project) aren’t interested in the ITProject, than this can have a huge impact down the complete chain, middle managers, project managers, developers and so on then do not think that their performance in this project is important for the company or their performance evaluations (and their payments) they start to focus on other projects and things (Kappelmann, McKeeman and Zhang, n.d., p.32). As an advice, the top management should always be clear that they have an eye on this project, maybe not the whole time, but that they are very interested in the outcome and are always there for help. This is leading to increased performance by the whole project team.

Misunderstandings between the customer and executive company

There always tend to be misunderstandings between the executive programming company and the customer. These especially happens if the customer is non-tech related at all and the executive company is having a less marked customer management and are not leading their client in what they need and what they can expect. The first and maybe the most important job of the executive company is to lead the customer, especially if they are not advanced in IT-Projects, and to give them a feedback about what is possible and reasonable, so that the expectations can be fulfilled and both sides will end the project in a good relationship. Researches have shown a gap between expectations and perceptions of projects outcome (Siddhartha, n.d., Chapter 2.2). This is referable to a bad customer management by the executive company. To avoid this as already said the managers needs to be clear to the customer, what is possible and what the company can do in the given amount of time. Do not lie to the customer and do not promise something that can’t be backed up, both will lead to a negative outcome of the project and will lead to further problems, e.g. the customer is trying to avoid the payment and no further orders are given to this company. Both should avoid weak definitions of requirements and poor estimates(Brenda Whittaker, 1999, p. Introduction). In short words – be realistic about what is possible and speak the truth to the customer and give him advice based on your experience.

#(Miss)managing Communication

One major task of the project manager is to achieve a good communication and atmosphere within the project team. It is absolutely necessary that the right information reaches the right person at the right time (Schwalbe, 2015, p.405). Important parts of the communication should be a fast one to get an answer if you need it at that exact moment, a famous solution for this is slack, which organizes your team in channels, direct messaging, share files and making phone calls are likewise possible (Slack, 2017). Meetings face-to-face and phone conferences are likely needed to form a team, a big conference meeting should be set up in an appropriate amount of time, e.g. every month or every quarter. E-Mail is still the way to tell important things or to communicate with the customer. To carry an extreme, an offer, or a report will never be send to the customer via WhatsApp.

Team size

A team is the better the smaller it is, this is coming from coordination overheat that is never be able to scale the same, the loss is there exponentially growing. Keep the team size as low as possible, if needed, a team can easier be expanded than be reduced. This also helps to lower the costs. A team size of 5 to 8 members is the optimum. Bigger teams are (due to the overhead) hard to control.

(Obsolete) programming language

At last there are fears that the language in which the team was developing is dropped by the coding community just after releasing the program or even while programming. This mostly impacts bigger projects or if the app is planned to be extended with new features. As programming company always have an eye on how programming languages perform overall and if they are still backed up and used by a large number of users. A good way to start is to look at the TIOBE Index. Here you can see the TIOBE Index of June 2017:

Figure 8: TIOBE Index of June 2017

The TIOBE Index is calculated by the number of search engine results for querying the name of the programming language. They use the 25 most popular search engines (Programming Languages Definition | TIOBE - The Software Quality Company, 2017). An alternative to the TIOBE Index would be the RedMonk-Ratings, which rely on number of projects on famous developer websites like github and the number of activities on stackoverflow (O’Grady, 2017). Companies should tend to use the programming language they are most used to, because the complexity of a new technology (or programming language,…) is always higher than with a familiar technology. As an example there are companies that are setting up web-apps with up to date javascript in the front end, but do to that they are having way more java developers then javascript who could set up the back end of the web-app in Node.js (Javascript) they are writing the back end in Java, which isn’t a bad language at all, but for this project consistency in the programming language would ease the things for the development team.

Conclusion

As a conclusion Project Complexity is one of the biggest reasons to exceed the timeline as well as the given budget, this is right not just for IT-Projects (Bosch-Rekveldt, 2011, chap.Abstract).

It is the most important for a project’s success to decide the right decisions early on the project. Due to the very hard scheduling and planning a project at beginning always plan buffer times.

• Use a programming language that your team is familiar with, don’t chase behind every new language, use one that is well known and a good choice for the given problem.
• Be fair to the customer, tell them honestly what is possible and what you can advice them based on your and your whole teams experience. Be realistic.
• Don’t add new tasks to the contract – stick to the contract, problems will always come up if you do not expect them.
• The top-management (in relation to the project) should show interest in the project, so all stakeholders will do the same.
• Find a good way to communicate with the team, the top-management and the customer.
• Keep the team as small as possible, sizes of 5-8 are handlebar the best.

Important is that a project can count as successful for the project manager, when all goals are met but it still can be a disaster for the client. This is often the case when the projects requirements are fulfilled, but they weren’t defined right at the beginning of the project (project kick-off) (De Wit, 1988).

Keeping all that in mind and learning from the last handled projects the next project should be working quite better than the last ones.

Table of figures

• Figure 1: The 5 stages of group development, Available at: https://www.luxoft.com/blog/spetkov/getting-a-new-agile-team-up-and-running-part-1-thekickoff-workshop/ [Accessed 20.06.2017].
• Figure 2: Chaos Summary 2000-2008, Available at: https://cours.etsmtl.ca/mti515/notes/cours01/chaos%20summary%202010.pdf [Accessed 20 Jun. 2017], Page 3.
• Figure 3: Chaos Summary 2011-2015, Available at: https://www.infoq.com/articles/standish-chaos-2015 [Accessed 20 Jun. 2017]
• Figure 4: AHP, Available at: https://en.wikipedia.org/wiki/File:AHP_TDHLeadImage.png [Accessed 25 Jun. 2017]
• Figure 5: Scale of Pairwise Comparion, Available at https://en.wikipedia.org/wiki/Analytic_hierarchy_process_%E2%80%93_leader_example [Accessed 25 Jun. 2017]
• Figure 6: Experience, Available at https://en.wikipedia.org/wiki/Analytic_hierarchy_process_%E2%80%93_leader_example [Accessed 25 Jun. 2017]
• Figure 7: Priority , Available at https://en.wikipedia.org/wiki/Analytic_hierarchy_process_%E2%80%93_leader_example [Accessed 25 Jun. 2017]
• Figure 8: TIOBE Index of June 2017, Available at: https://www.tiobe.com/tiobe-index/ [Accessed 19 Jun. 2017].

Table of references

• Anon 2016. Analytic hierarchy process – leader example. In: Wikipedia. [online] Available at: <https://en.wikipedia.org/w/index.php?title=Analytic_hierarchy_process_%E2%80%93_lead er_example&oldid=754942782>.
• Anon 2017. Git. [online] Available at: https://git-scm.com/ [Accessed 20 Jun. 2017].
• Anon 2017. Programming Languages Definition | TIOBE - The Software Quality Company. [online] Available at: https://www.tiobe.com/tiobe-index/programming-languagesdefinition/ [Accessed 19 Jun. 2017].
• Anon 2017. Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch. [online] InfoQ. Available at: https://www.infoq.com/articles/standish-chaos-2015 [Accessed 20 Jun. 2017].
• Anon n.d. BruceTuckman_Team_Development_Model.pdf. Available at: http://www.sst7.org/media/BruceTuckman_Team_Development_Model.pdf [Accessed 19 Jun. 2017].
• Anon n.d. chaos summary 2010.pdf. Available at: https://cours.etsmtl.ca/mti515/notes/cours01/chaos%20summary%202010.pdf [Accessed 20 Jun. 2017].
• Bosch-Rekveldt, M.G.C., 2011. Managing project complexity: A study into adapting early project phases to improve project performance in large engineering projects. [online] Available at: https://repository.tudelft.nl/islandora/object/uuid:a783e581-bc7a-4efa-adcb7e9201840367?collection=research [Accessed 20 Jun. 2017].
• Brenda Whittaker, 1999. What went wrong? Unsuccessful information technology projects. Information Management & Computer Security, 7(1), pp.23–30.
• Brooks, F.P.J., 1974. The Mythical Man-Month. [online] Available at: http://moosehead.cis.umassd.edu/cis365/reading/Mythical_Man_Month.pdf [Accessed 25 Jun. 2017].
• De Wit, A., 1988. Measurement of project success. International journal of project management, 6(3), pp.164–170.
• Flyvbjerg, B. and Budzier, A., 2011. Why Your IT Project May Be Riskier than You Think. [SSRN Scholarly Paper]
• Rochester, NY: Social Science Research Network. Available at: https://papers.ssrn.com/abstract=2229735 [Accessed 19 Jun. 2017].
• Kappelmann, L.A., McKeeman, R. and Zhang, L., n.d. Early Warning Signs of IT Project Failure: The Dominant Dozen. [online] Available at: http://ismjournal.com/ITToday/projectfailure.pdf [Accessed 20 Jun. 2017].
• Loeliger, J. and McCullough, M., 2012. Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development. O’Reilly Media, Inc.
• O’Grady, S., 2017. The RedMonk Programming Language Rankings: June 2017. [online] tecosystems. Available at: http://redmonk.com/sogrady/2017/06/08/language-rankings-617/ [Accessed 20 Jun. 2017].
• Schwalbe, K., 2015. Information Technology Project Management. Cengage Learning.
• Siddhartha, A., n.d. PERCEPTIONS & EXPECTATIONS OF THE ROLES & FUNCTIONS OF THE IT PROJECT MANAGEMENT OFFICE. Available at: http://www.pacisnet.org/file/2013/PACIS2013-277.pdf [Accessed 19 Jun. 2017].
• Silvera, J.L.S. and Nieto, A.M., 2010. Formal methodologies for modelling IT projects Critical Success Factors. [online] XIV International Congress on Project Engineering. Madrid. Available at: http://www.aeipro.com/files/congresos/2010madrid/ciip10_2570_2579.2962.pdf [Accessed 21 Jun. 2017].
• Slack, 2017. Slack: Where work happens. [online] Slack. Available at: https://slack.com/is [Accessed 20 Jun. 2017].
• Vidal, L.-A., Marle, F. and Bocquet, J.-C., 2015. Measuring project complexity using the Analytic Hierarchy Process. Available at: https://hal.archives-ouvertes.fr/hal01215358/document [Accessed 25 Jun. 2017].
• Wallace, L., Keil, M. and Rai, A., 2004. How Software Project Risks Affects Project Performance: An Investigation of the Dimensions of Risk and an Exploratory Model. [online] Available at: https://pdfs.semanticscholar.org/ff49/138dc6cc4fbbe9b1d1c9623ffed1b2d404ab.pdf [Accessed 20 Jun. 2017].