Why Internal Project Management mostly fails? - Theo Van Stratum - Student Publications, Research, Projects, Investigation and Academic Work presented by Atlantic International University students, faculty and other contributors. Bachelor, master, doctora

Student Publications

Author: Theo Van Stratum
Title: Why is it that Internal Project Management mostly fails?
Area:
Country:
Profile:
Program: Doctorate of Science in Information Technology
Available for Download: Yes

Sharing knowledge is a vital component in the growth and advancement of our society in a sustainable and responsible way. Through Open Access, AIU and other leading institutions through out the world are tearing down the barriers to access and use research literature. Our organization is interested in the dissemination of advances in scientific research fundamental to the proper operation of a modern society, in terms of community awareness, empowerment, health and wellness, sustainable development, economic advancement, and optimal functioning of health, education and other vital services. AIU’s mission and vision is consistent with the vision expressed in the Budapest Open Access Initiative and Berlin Declaration on Open Access to Knowledge in the Sciences and Humanities. Do you have something you would like to share, or just a question or comment? We would be happy to hear from you, please use the Request Info link below.

For more information on the AIU's Open Access Initiative, click here.


	Acknowledgements I wish to thank: Mr. Iain Clark from Albanet Limited for the support he gave me in believing that I could do this study and in the way he created the opportunity for me to do this. Dr. Franklin Valcin for his encouragement and advice during my time with the Atlantic International University. Last but not least my wife Maureen van Stratum for the unlimited support during the time it took me to reach this point. Inverness, 2 March 2006 Theo van Stratum Page 1 19/03/2006 Why is it that Internal Project Management mostly fails? Abstract This paper discusses the reason why there is a more likelihood that a project, led by an internal project manager, fails the led by an external project manager. This research is done by interviewing project managers in software development, internal and external, to see if there is a common ground for this and if there is a way to follow and avoid this failing. Although the research is done in this area there is enough evidence to believe that the reasons found are similar in other project management areas. The paper describes the general differences between the work systems, experience, and methods used by the two groups of managers. In general we see that the external project managers have more experience, and with that the authority to handle projects and their conflicts in a way that the project keeps on track. The internal project manager lacks this authority by his colleagues and managers and they could interfere with the project in more then one way and endanger the project with those actions. Further is the lack of the use of a formal method to lead and register the project one of the biggest causes of failure. Things like: User requirements, Feature creeping, Change and risk management are more likely to be in place with am external project manager then an internal project manager. This is sometime not even by choice but forced due to costs. This is especially the case within the triangle of constrain where we see the three main control places of a project: Cost, Time, and Quality. No single person or group should be allowed to be in control of all three of them, but in the case of internal project management we see that this is mostly the case. If there is an alteration in one of the three points the project manager must be allowed to change the others accordingly and this is not always done and brings the project in danger. As recommendation we see that proper training of the internal project manager in a formal method is a must, and if this is combined with a mentor during the first project, we will increase the success rate of internal project manager drastically. Theo van Stratum Page 3 19/03/2006 Why is it that Internal Project Management mostly fails? This page is intentionally left blank Theo van Stratum Page 4 19/03/2006 Why is it that Internal Project Management mostly fails? Chapter 1: General Introduction In the many projects I have done over the years I came across a phenomenon that gave me the idea for this research. It appears that projects that are carried out by internal project managers have a higher failing rate than the same type of projects led by external project managers. In a small investigation amongst my peers I came to the conclusion that this problem is broader than expected and with and average failing rate of 65% with internal project management or more against 28% with an external project manager, a research into this phenomenon seems appropriate. Failing rate 80 70 60 e 50 tag Internal PM 40 cen External PM 30 erP 20 10 0 Failed Succesful Figure 1: Failing percentage Internal versus External PM. In figure 1 we see that the failing percentage of internal project management versus external project management is too high to coincidental. These figures are taken over 593 projects, equally divided over internal and external project management, over the last two years (2004, 2005). Companies are losing millions per year due to this phenomenon still, i t seems that there is no learning curve within those companies to stop this from happening again and losses are taken on face-value. This is especially true with in organizations that are not driven by profit like Government and semi- Government. As an example we can take the construction of the Government Theo van Stratum Page 5 19/03/2006 Why is it that Internal Project Management mostly fails? building in Scotland (Edinburgh), which went 10 times over it original budget and took 2.5 years more then planned. There where external project leaders in place to do the actual work on the floor but the overall project management was done by an internal project bureau. Although there was an enquiry, real action to solve this wasn't taken. If there is a common approach or cause, then the knowledge of such could prevent project managers to make the same mistake over and over again and save the economy millions. The intension of this research is to find such a common cause. During the research it was necessary to redefine the common definition of failing of a project. Amongst the enquired project managers we noticed that the definition about failing a project was very diverse: from abandoning a project to failing to deliver on time. The definition in this document about failing a project is as follows: "A project appears to be failed if the outcome of the project is not within time, cost, or quality, defined at the start of the project or after changes made through approved change requests." The parameters: Time, Cost, and Quality are parts of the triangle of Constrain, which plays, as we will later see, an important role in project management. From this new perspective we can see that a project can be finished with the desired product or service but still is failed within the definition of failing. The project could have cost more, took longer, or not all the requirements where implemented. Research restrictions The researched projects were limited to software development projects only. These are the best documented and traceable in historic events during implementation. The enquired project managers were in the range of Theo van Stratum Page 6 19/03/2006 Why is it that Internal Project Management mostly fails? professional project managers to the occasional, temporary, project manager. The reason for this differentiation was to get an insight in the approach of managing and failing of the projects. Theo van Stratum Page 7 19/03/2006 Why is it that Internal Project Management mostly fails? Chapter 2: Definition of the Investigation As described in the previous chapter this research is restricted to the area of software development. The problems encountered are more general and not restricted too software development only but the area is take due to the fact that the processes used are more approachable for research purposes. Areas of project management Figure 2: Areas of influence (drawn by author) In figure 1 we find the areas around a project that are of influence of the outcome of that project. As Richard Newton (2005) mentioned; "A Project Manager needs to look over the boundaries of his or her project". What he means by this is: that beside the problems a project manager encounters in his or her project, there are external influences that could have a bigger effect on the outcome of the project then at first evaluated. There are influences were the project manager, nor the company, is in control off. A few of those external influences are, but is not exclusive to this list: External Influences: - Funding, - Market demand changes, - Change of external politics and values, - Technology. Theo van Stratum Page 8 19/03/2006 Why is it that Internal Project Management mostly fails? Funding In the case of losing external funding, investors are rejecting their funding to the company or project, the project is doomed to fail unless the company could raise other funds. The project manager is not in control of this but needs to investigate (as far as this is known in this point in time), before starting the project, if adequate funding is available and/or reserved for the project. In principal it means that an investigation into the solvency and cash flow of the company needs to be done. In the case of the project managers interviewed for this research I found that this was never done and the responsibility of the funding towards the projects was placed by the responsible directors. Although this is a sound approach we must remember that in the case of an internal project manager this is very difficult to do as the directors involved could be offended and it could be on influence of the career path of the persons involved, but on the other hand we will have the same problem when the project fails and the finger is pointed towards the project manager as cause of failing. Market demand changes This is happening when the product or service developed in the project is overtaken by new demands and or developments in the market. Most of the time caused by the fact that the time to market for the product or service is to long and competitors have the time to develop a new, better, product before the project is finished. Again not something the project manager is in control off but adequate market monitoring could indicate early enough that a demand change is on the merge and the project manager can react on this before the event occurs. Although market monitoring should be an active task for the directors of a company, in the case of a project of which the outcome is to fulfil a market demand the project manager shares the responsibility in this. Theo van Stratum Page 9 19/03/2006 Why is it that Internal Project Management mostly fails? Change of external politics and values When Ethical and/or Political values are changing in a way that it has an influence on the project outcome (the product that is developed is not ethical or politically correct anymore) means that the project is obsolete and needs to be abandon or changed in a way that the product or service falls within the new legislation or ethical values. Again monitoring this should be a company/directors task but a project manager could be active in this as well. Technology When technologies changes during the project, and this is especially valid in long running projects, a choice needs to be made if the project is still valid to finish or if technologically adjustments need to be included. As usual this is a question of funding and market demands and should be made by the directors of the company. As an example we can look at the new development of the operation systems of Microsoft. In the last few year this is changed for development advantages with the new dot.net Framework. If you are running a development project you will face the question: are we adopting the dot.net framework or not. Of course there will be a lot of parameters included in this decision like: how far are we from completing? What is the cost involved in changing: time, training, and so on. Is it better to finish now on older technology and adapt to dot.net in a later version? All of the external influences are outside the scope of control of the project manager but close monitoring of the external environment can give clues early enough for the project manager to react proactive. Theo van Stratum Page 10 19/03/2006 Why is it that Internal Project Management mostly fails? Triangle of Constrain If there is one thing a project manager should know about engineering something then it is the Triangle of Constrain (see Figure 3) Figure 3: Triangle of Constrain Cost is the measure of how many people, engineers and overhead like secretaries and so no, are working for the project, Time is the measure of how long the project has to finish, and Quality is the measure of how mane features (user requirements) and testing (Quality Control) will be allowed within the project scope, Controlling time, cost, and quality are all important goals which need to be under control but nobody should be in total control of all three of them. If the customer, or manager, arbitrarily specifies all three corners of the Triangle of Constrain, then the project is doomed to fail. Any change to one of the corners must be balanced off by changes in the other corners. The moral is that if the project is to be successful, the project manager must be permitted to make the necessary adjustments to at least one of the goals. Theo van Stratum Page 11 19/03/2006 Why is it that Internal Project Management mostly fails? In the 1990s, NASA briefly adopted the slogan `Faster, cheaper, better.' This was followed by a series of unsuccessful projects � and then they abandoned the slogan. It is important to realize that, pushed to the limit, the `Faster, cheaper, better' slogan is impossible to satisfy. It is absurd a statement as `I can fly'. There is a saying among software engineers that corrects the statement of NASA's praiseworthy but impossible goal: `Faster, cheaper, better: pick two out of three.' Ownership Ownership of a project needs to lie by a director, or somebody from senior management, is a must for a project to succeed. The reason for this is that it gives a project status and priority with in the company from a higher management perspective. When resources and funding needs to been allocated to several projects the owner is mostly in the position to make decisions and could influence that the projects he owns, is responsible for, will get the needed funding. Company politics / strategy Company politics are very important and are tied with company strategy. They could influence the future of a project. If the companies' strategy is changes it could mean that project can becoming obsolete. This doesn't mean that a project fail in the sense of this research but as priorities are changing with strategy it could mean that projects are becoming lower in importance and with that the change of failure becomes more realistic. Other projects As always there are only limited resources available within a company and several projects will compete for those resources. As explained in the Triangle of Constrain: if there is a loss of resources then alterations need to be made in the time and/or quality of the project. This is a threat in a running project especially where a resources is just lend for a small task to another project. Theo van Stratum Page 12 19/03/2006 Why is it that Internal Project Management mostly fails? We must make sure that action is taken against such activity and to adjust the project planning accordingly. Office politics This is a grey area within project management and working for a company in general. Office politics is about power play between colleagues and can be of an enormous influence on the project. If the project manager is respected and the project has a high priority within the company that this influence will be low or even be an advantage. But if the project manager is temporary chosen from the staff and bad feelings about this are amongst the colleagues then this phenomenon could be the cause of failure on its own. All the above described `external' influences on projects are mostly not in the power-reach of the project manager and are difficult to manage, but if the project manager wants to finish his project successfully then monitoring of those external influences is a necessity at all times. Theo van Stratum Page 13 19/03/2006 Why is it that Internal Project Management mostly fails? Internal Project influences The following issues in project management are common and everybody is taking them on face-value, but a lot of projects are failing just because of that. Keep in mind that according to the interviewed project managers most of the problems within the project are forced and with that not in their own control anymore. Project definition Although very logical, you must have a project definition (a goal) you are working towards; it seems that this is a mostly forgotten or underestimated part of the project. In the questionnaire, which we will discus in the next chapter, we had a few questions about Project definitions and user requirements and we saw that in the case of a project definition only 25% of internal projects had one. This means that in 75% of the internal projects the teams didn't really know what they where making! In the case of software projects we see that the common line from management is: "You know what I want, don't you?" As V.A. Vyssotsky (The Mythical Man-Month (2004) pp 142), of Bell Telephone Laboratories' Safeguard Project says, "The crucial task is to get the product defined. Many, many failures concern exactly those aspects that were never quite specified" User requirements As the project definition gives us a general frame work of what the customer wants, the user requirements should be very specific and non-ambiguous. It tells us what it is that the outcome of the project should have or not have. If we take a software building project then the user requirements should tell us exactly the business-rules for the product. Appropriate time should set aside in the project planning to get all the user requirements on paper. Although we must be aware that in very long running projects it is not always the right way to go by defining all the user requirements as an initial step. We have seen in the paragraph above that projects are chancing over time and with that the Theo van Stratum Page 14 19/03/2006 Why is it that Internal Project Management mostly fails? user requirements. We will see later in the document how we can handle this in an appropriate way. Feature creeping Feature creeping is one of the biggest causes of project failure, in the research done we saw that more then 95% of projects are suffering from this. A feature if nothing more then an enhancement of the final product, it can go from a nice to have till a must have and every project manager has to deal with them. They are un-avoidable in real-life. It is only the way they are dealt with. If we are looking at the triangle of constrain we that on the right lower corner we have quality as a measure point. Qualities are the features in a product so according to the triangle of constrain if we add features then we must accordingly alter one or all of the other measure points, time and costs. With in feature creeping this is normally not done. Under the saying: "O, this is only a small thing to adjust or to add" a feature is added to the project and the project start to run out of cost and or time before we know it. Quality Control Quality control is where the quality of the project and product is monitored. It ensures us that all the user requirements are implemented and tested that they work in the way it is described in the requirements. This begins long before we are even starting to build anything. As Brooks mentioned (2004): "Specifications, user requirements, need to be tested on their completeness and clarity." and needs to be handled by an outside testing group. This is especially true in software engineering projects, as Vyssotsky says; the developers themselves cannot do this: "They won't tell you they don't understand it; they will happily invent their way through the gaps and obscurities". Theo van Stratum Page 15 19/03/2006 Why is it that Internal Project Management mostly fails? Project management methodology There are several approaches that can be taken to project management, including phased, incremental, and iterative approaches. The "traditional" approach identifies a sequence of steps to be completed. This contrasts with the agile software development approach in which the project is seen as relatively small tasks rather than a complete process. The objective of this approach is to impose as little overhead as possible in the form of rationale, justification, documentation, reporting, meetings, and permission. This approach may also be called the "spiral" approach, since completion of one of the small tasks leads to the beginning of the next. Advanced approaches to agile project management, applicable not only to software development but to any area, utilize the principles of human interaction management to deal with the complexities of human collaboration. Technology switching Technology switching during a project is expensive and a dangerous thing to do. We see this type of actions mostly in software projects where designers, programmers, and so on come across a new language (like C# in the last years) and start to redesign the project in such a new language. Of course this is deadly from a project management point of view, although it is not always possible to avoid this. Especially in the case of Company politic to always follows the latest technology. All the subjects that are described above are points of failure when not proper handled or monitored according to the interviewed project managers during the research. Theo van Stratum Page 16 19/03/2006 Why is it that Internal Project Management mostly fails? Chapter 3: Dynamics of the anticipated Solution The goal and Objective of this research As described in the question of this research: "Why is it that Internal Project Management mostly fails" I try to find the reasons behind the phenomenon that over 65% of projects that are led by internal project managers fail. If there is a specific reason for this then knowledge about this can lead to a solution or methodology to increase the success rate of future projects. The questions that came up where: - Is this happening due to inexperience in project management? - Is it more likely to happen in projects that are in an unknown area for the project manager? - Which methodology is used, if any? - Is it market specific, in other words: is it specific to a type of project? (software engineering, design and so on) In general literature about project management we find everything about methodology and techniques, how to report and on what, but what they don't try to teach is the fact that project management in the first place is "managing of people". When I was researching this and interviewing project managers about the way they work and what they were thinking the failure was, then all the points from chapter 2 where mentioned but nobody was talking about the people behind this failure points. Because of this and my feeling that one of the most difficult task a project manager has is the human interaction, if it is the man on the work floor or the director in the boardroom, the project manager must communicate on their level but not only that, he must also translate between those levels to make sure that they understand each other. Which brings me to the second goal of this research; "Is communication the biggest point of failure within project management?" Theo van Stratum Page 17 19/03/2006 Why is it that Internal Project Management mostly fails? Methodology used For the main part of information gathering I used quantitative research via a questionnaire. The reason for this type of data gathering is that is cheaper and not that labour intensive. The questionnaire was email based and sent to over 500 project managers over the world. Because the questionnaire was on personal application the response rate was very high, 76% of the questionnaires sent, returned. As said before the projects in this research came all from software engineering. It is however my strongest believe that the results will be the same in every other form of project management due to the fact that people will find the same problems and solutions everywhere. Questionnaire The questionnaire was built in 4 groups of questions: 1. Experience a. Years in project management, b. Professional certification, c. Number of projects done, i. How many successful, ii. How many failed, iii. How many abandon, 2. Methodology normally used, a. Which one, if any i. Officially trained in it, ii. Waterfall �method iii. Agile method b. If any followed completely, c. If any, was it helpful, d. How much time spend in following the rules e. If not, why, f. Was risk management in place, g. Was change management in place, 3. Projects Theo van Stratum Page 18 19/03/2006 Why is it that Internal Project Management mostly fails? a. How many External i. On average: 1. Project budget 2. Number of resources 3. Estimated project time b. How many Internal i. On average: 1. Project budget 2. Number of resources 3. Estimated project time c. Success rate External d. Success rate Internal e. Looking at the failed projects, if any, what would be the area of failing, i. Time (project took longer then estimated, ii. Cost (project was more expensive then estimated) iii. Quality (not all the user requirements where implemented), f. What was, according to you, the main cause of failing (average over the failed projects), g. Do you have an exit plan in place? h. Do you hold post-mortem sessions? i. Where users constantly involved. j. How much time was taken for testing, in percent of total project time, After the questionnaire 20 project managers where selected, to get a broad range as possible, for personal interviews to get a deeper understanding on the success and failing rate in this area. The selection criteria for those project managers was that they all had to have done internal and external projects whilst one half of the group needed to have more failures in the internal projects and the other half needed to be more successful overall. Theo van Stratum Page 19 19/03/2006 Why is it that Internal Project Management mostly fails? Interviews The interviews where done in person, over the phone, or by direct internet communication (chatting). All the questions where open ended and none of the project managers where given the questions in advance. Because of this we ended in most case in an open discussion. This gave me a good inside in the way project managers are thinking. I found in general that first time project managers are optimists and believe in a happy ending. Theo van Stratum Page 20 19/03/2006 Why is it that Internal Project Management mostly fails? Chapter 4: Overall Outcomes From the 500 questionnaires sent, 382 where returned which gives a return percentage of 76.4%. In total 593 projects where taken by those project managers in a time period of 2 years. Years in project management years in project management 9+ 0 - 3 4 - 8 Figure 4: Years in Project management On the question: "How many years experience of project management do you have we see that the division between the group form 0 � 3 and 4 � 8 is equal, respectively: 176 and 179, whilst only a small group (27) has more then 8 years of experience. The group from 0 � 3 years of experience was asked the question if this was their first project and 83 answered positive on this (46.36%). Only 13.35%, 51, of the project managers had a professional, all PRINCE II, certificate and from those 51 managers none of them was in the 0 � 3 experience group. Theo van Stratum Page 21 19/03/2006 Why is it that Internal Project Management mostly fails? Number of project done in the last 2 years Number of projects done 9+ 31 4 - 8 0 - 3 248 314 Figure 5: Number of projects On the question how many projects are done in the last two years we see that in the experience group 0 � 3 the most projects are done, 176 project managers did 314 projects, This is 1.8 project per project manager, whilst with the more experienced project managers this is lower, 1.4 in the group 4 � 8 years, and 1.1 in the 9+ group. On the sub-question: How many projects do you run at the same time? We see that in the group with the less experience the most projects are done in the same time or overlapping. With the average of 2, whilst in the group with the highest experience all of the project managers are doing only 1 project at the time. Theo van Stratum Page 22 19/03/2006 Why is it that Internal Project Management mostly fails? On the question: "How many were successful, according to this research success definition?" Number of projects successful 9+ 29 0 - 3 43 4 - 8 89 Figure 6: Projects successful In the group 0 � 3 we see that only 13.7% of the projects done are successful, that is: within time, costs, and quality expected. The group 4 � 8 is slightly better: 35.9%, whilst in the 9+ group 93.5% of the projects were successful. In total only 27.2% of the projects were successful if measured again the research parameters, which is worrying for the quality of project management in software engineering. Theo van Stratum Page 23 19/03/2006 Why is it that Internal Project Management mostly fails? Methodology used 200 180 160 140 120 Project managers 100 Methodology used 80 Officially trained 60 40 20 0 0 - 3 4 - 8 9+ Figure 7: Methodology used On the question if a methodology is used we see that the more experience a project manager has the more a project methodology is used and officially trained in the method. On the question which methodology the answer was consistently PRINCE II, which is not surprising in software engineering where PRINCE II is the main methodology. Within project management we see that the agile project management method is rising but when the question about this was asked we saw that only 7% was using this, not including the project managers that where not using a methodology and the rest, 93%, uses still a form of waterfall method. On the question if the method was followed completely through none of the project managers did this and all were using some form of adjustment in the workflow. Most of the ones that where using a method found this useful and giving them peace of mind. The project managers that didn't follow an official methodology were asked why did was and 87% didn't know how to but would be willing to learn whilst the other 13% did saw the need in them due to the fact that their projects Theo van Stratum Page 24 19/03/2006 Why is it that Internal Project Management mostly fails? where very small and they thought that the hustle in maintaining the documentation around the projects would be too costly in time. In the case of risk management, what are the risks in the project that could be the cause for failing, we see that only 45% of the project managers actively looks at the risks and register them against the task involved. The idea of risk management is that contingency plans are developed in the case the event occurs. Change management was in place in over 55% of the projects. Divided over the experience groups give us the following overview Change Management per experience group 350 300 ects 250 roj 200 P Project done 150 Change management er ofb 100 um 50 N 0 0 - 3 4 - 8 9+ Years Experience Figure 8: Change Management Theo van Stratum Page 25 19/03/2006 Why is it that Internal Project Management mostly fails? Projects Ex versus Internal projects per experience group 350 300 ects 250 roj Projects done 200 P External projects 150 er of Internal projects b 100 um 50 N 0 0 - 3 4 - 8 9+ Years Experience Figure 9: External versus Internal Projects On the question how many external versus internal projects are done with in the experience group we see that there are more internal project done by the less experience groups than the higher experienced ones. 60% in 0 � 3 group, 39% in the 4 � 8 group, and only 13% in 9+ group. The average project budget was Table 1: Project Budgets Experience group Internal Projects External Projects 0 � 3 $ 5.000 - $ 12.500 $ 10.000 - $ 26.000 4 � 8 $ 4.500 - $ 23.500 $ 17.000 - $ 150.000 9+ $ 8.000 - $ 50.000 $ 25.000 - $ 1.250.000 The budgets are recalculated to dollars The average number of resources in projects Table 2: Number of Resources Experience group Internal Projects External Projects 0 � 3 3 � 5 3 � 5 4 � 8 2 � 7 5 � 12 9+ 2 � 8 8 � 25 Theo van Stratum Page 26 19/03/2006 Why is it that Internal Project Management mostly fails? The average project time (elapse time) Table 3: Project time Experience group Internal Projects External Projects 0 � 3 13 � 15 weeks 12 � 14 weeks 4 � 8 12 � 17 weeks 13 � 20 weeks 9+ 13 � 30 weeks 17 � 50 weeks On the question: "Looking at the failed projects, what would be the area of failing?" This question is very subjective and the interviewed project manager could give more then one answer. The idea behind the question was to get a feeling of what the project manager him self though what the biggest problem was. The figures are in percentage average over the projects Table 4: Cause of failing Experience group Time Cost Quality 0 � 3 75% 95% 35% 4 � 8 87% 81% 40% 9+ 56% 25% 10% Exit plan An exit plan is planning for failure. If we are thinking of project management then most project managers are thinking of success but if we see the failing rate then we should think about failure as well. What are we going do to if the project fails, and need to be abandoned? This is described in an "exit plan". When the question was asked only 1 project manager had used an exit plan. Post Mortem Sessions To learn from previous projects it is always good to have a post mortem session after finishing a project, if it was a success or failure you can learn from it and repeat the good things and try to avoid the bad ones. From the project managers interviewed none had used a post mortem at all. The main argument was that there was no time and budget reserved for this. Theo van Stratum Page 27 19/03/2006 Why is it that Internal Project Management mostly fails? Involving Users This was to see if users are actively involved in the project. The effect of involving users can be good, if the project manager handles this correct. In the agile project and development methods it is common that the users are part of the project team. This way they can make sure that the customer gets what he has paid for. Only 36% of the projects done had a close relationship with their users and this was the same in all the experience groups. Testing Due to the fact that the project managers interviewed came out of the software development area we had a question about testing, which is in every software development project a hot item. On the question: "How much time was taken for testing, in percent of the total project time" we got the following figures: Table 5: Testing time Experience group internal external 0 � 3 5% 7% 4 � 8 12% 17% 9+ 8% 21% . The interviews were more to get a global overview about how a project manager thinks when working on his project. There are not direct measurable figure but the outcome from those interviews are incorporated into the analysis of this research. Theo van Stratum Page 28 19/03/2006 Why is it that Internal Project Management mostly fails? Elapse Time versus Working Time A common problem within project management is the difference between working time, man-days, and elapse time, project time. The problem is that when project managers estimate the task project times they take a man-day for an eight-hour working day and this is unrealistic. Nobody is working 100% of its time per day. For my own projects I did an investigation into this and used my own group of programmers to write their time down, for a period of 8 weeks, in everything they did. We came to the conclusion that the disturbance of telephone, meetings, questions, getting and drinking tea and coffee, and having sanitary stops is taking a lot of time away from the working hours. Average over the group and eight-weeks we saw that between 60 and 75% effective working time was left for planning. What does this means in planning? When the project times are estimated we must first calculate the man-days (man-hours) and value them at the percentage we take for effective programming time for that programmer, this can be different for each of the programmers involved, and then recalculate them for project elapse time. If we say that a task cost 10 hours and we have an effeteness of 70% then the elapse time for that task is 14 hours. Theo van Stratum Page 29 19/03/2006 Why is it that Internal Project Management mostly fails? This page is intentionally left blank Theo van Stratum Page 30 19/03/2006 Why is it that Internal Project Management mostly fails? Chapter 5: Analysis Experience Although I couldn't find a lot of project managers with 9+ years of project management experience we can see that the success of bringing a project to a successful end is related to experience, success rate in % versus experience in years 100.00 90.00 80.00 70.00 60.00 50.00 success rate in % 40.00 30.00 20.00 10.00 0.00 0 - 3 4 - 8 9+ Figure 10: Success rate versus experience We see that the project managers with more experience are using a methodology to manage their projects in a structured way. In the interviews with the project managers it was clear that when they had an official training in a method the chance in success was higher. What was clear however, was that when a method was used within several projects, the manager was changing the way the method was used from a rigid following towards a "use what you need approach". The latter was according to the managers more useful. With the implementation of a methodology we see the implementation of two techniques, which are a must for successful project management. Theo van Stratum Page 31 19/03/2006 Why is it that Internal Project Management mostly fails? Risk Management Generally, Risk Management is the process of measuring, or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management, which is discussed here, focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments. Regardless of the type of risk management, all large corporations have risk management teams Risk management versus Experience 80% 70% 60% 50% 40% Risk management 30% 20% 10% 0% 0 - 3 4 - 8 9+ Figure 11: Risk Management versus Experience As we can see in figure 11, the implementation of risk management follows the same line as in the implementation of a project management methodology although there is a steeper line after the 4 � 8 years experience which let us to believe that the insight in the risks of a project and the need to manage them in a structured way come with more experience over the years. What was disappointed however is that even with the most experienced of the interviewed project managers not all of them saw the need to implement. Theo van Stratum Page 32 19/03/2006 Why is it that Internal Project Management mostly fails? Limitations of risk management If risks are improperly assessed and prioritised, time can be wasted in dealing with risk of losses that are not likely to occur. Spending too much time assessing and managing unlikely risks can divert resources that could be used more profitably. Unlikely events do occur, but if the risk is unlikely enough to occur, it may be better to simply retain the risk, and deal with the result if the risk does in fact occur. Prioritizing too highly the Risk management processes itself, could potentially keep an organization from ever completing a project or even getting started. This is especially true if other work is suspended until the risk management process is considered complete. Change Management One of the biggest challenges of project management is how to cope with feature creeping. Feature creeping is the phenomenon that feature, quality, is added to the project without adjusting the resources and/or time components of the triangle of constrain, see figure 3. The rules of the triangle of constrain tells us that if we alter one of the corners; costs, quality, and time, we must alter at least one of the other corners to compensate for the change. Change management versus experience 120% 100% 80% 60% Change management 40% 20% 0% 0 - 3 4 - 8 9+ Figure 12: Change management versus experience Theo van Stratum Page 33 19/03/2006 Why is it that Internal Project Management mostly fails? In figure 12 we see that the curve of the implementation of change management versus experience is the opposite of the curve of implementation of risk management. The reason for this is clear in the sense that added features have a direct noticeable effect of the project progress and the need to protect the project team is high. Although in internal, and in someway external, project management we see that feature creeping is done in a subtle way like, "this will only take a few minutes", or "adding this will gives us time later because....". Most of the time this is done by the sales team with the backup of directors and the project manager is forced into a move that can cause the project to fail. The rules of the Triangle of constrains are not followed and that is always a bad thing. Estimating and Scheduling In the interviews came across that the estimating of cost and time necessary for the project on hands is not always strait forward. Especially beginning project managers have problems with this. In general estimating how much time a task will cost is based on historical data, previous projects done. For the beginning project manager, this is not available other then projects done by other project managers. This means that he must rely on the assumed correctness of this data. Another way is doing the estimate is to take mathematical models as described below. In the book "The Mythical Man-Month", Brooks describes the problem of the man-month. The time unit used to estimate effort versus time used. Brooks mentioned: "Cost varies as the product of the number of men and the number of months. Progress does not." It is very dangerous to use a man � month (week or day) to measure the task on hand. It implies that men and months are interchangeable. This is only true if the task can be partitioned amongst many workers with no communication amongst them. This is true of picking strawberries or cotton; but in any task where communication between the Theo van Stratum Page 34 19/03/2006 Why is it that Internal Project Management mostly fails? team members is a necessity this fails. When a task cannot be partitioned because of sequential constrains, and then adding more men has no effect on the schedule. In software engineering this is common due to the sequential nature of debugging. In tasks that can be partitioned but which require communication amongst the subtasks, the effort of communication must be added to the amount of work to be done. Therefore the best that can be done is somewhat poorer then a trade of men for months. Intercommunication Intercommunication between team members increase the effort needed to complete the task. If each part of the task must be separately coordinated with each other, the effort increases with n(n-1)/2. Three workers require three times as much pair-wise intercommunication as two; four requires six times as two. If, moreover, there need to be conferences among three, four, etc. workers to resolve things jointly, matters get worse yet. Algorithmic cost modelling The most systematic, although not necessarily the most accurate, approach to calculate the estimate in man-months in software engineering is algorithmic cost estimation. An algorithmic cost model can be built by analysing the costs and attributes of successful completed projects. A mathematical formula is used to predict costs based on estimates of projects size, number of programmers and other process and project factors. In its most general form, an algorithmic cost estimate for software cost can be expressed as: Effort = A x Sizeb x M A is a constant factor which depend on local organisational practices and the type of software that is developed, Size may be either an assessment of the code size of the software or a functionality estimate expressed in function or Theo van Stratum Page 35 19/03/2006 Why is it that Internal Project Management mostly fails? object points. The value of exponent B usually lies between 1.0 and 1.5. It reflects the disproportionate effort required for large projects. M is the multiplier made up by combining different process, product and development attributes. All algorithmic models suffer from the same basic difficulties: - It is often difficult to estimate Size at an early stage in a project where only a specification is available. Function point and Object point estimate are easier to produce than estimates of code but may still be inaccurate. - The estimates of the factors contributing to B and M are subjective. Estimates vary from one person to another depending on their background and experience. The number of line of source code in the finished system is the basic metric used in most algorithmic cost models. There are a number of algorithmic models that have been proposed as a basic for estimating the effort, schedule and costs of a software project. These are conceptually similar but use different parameter values. COCOMO Model COCOMO is a model designed by Barry Boehm to give an estimate of the number of programmer-months it will take to develop a software product. This "COnstructive COst MOdel" is based on a study of about sixty projects at TRW, a Californian automotive and IT company, acquired by Northrop Grumman in late 2002. The programmes examined ranged in size from 2000 to 100,000 lines of code, and programming languages used ranged from assembly to PL/I. COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. Theo van Stratum Page 36 19/03/2006 Why is it that Internal Project Management mostly fails? - Basic COCOMO - is a static single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code. - Intermediate COCOMO - computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes. - Advanced COCOMO - incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process. One of the most important observations in the model is that personnel motivation overwhelms all other parameters. This would suggest that leadership and team man ship are the most important skills of all, but this point was largely ignored. Researchers would rather create tools. Personnel motivation is not part of the model. The single most important driver is software complexity, followed by personnel attributes (capability and experience, not motivation). Methodology In the research we saw that the more experience a project manager is the incline to use a project management methodology. This is, however, less in internal projects. From the interview we can deduct that by pressure from management there is mostly no time taken for implementation of the formal method. The deadlines are set before the project description is written. Project description and Goal No project manager should start a project without a proper project description, we would say that this is obvious but during the interviews it became clear that most of the less experienced project managers had problems to get a proper description of what to build from the customer. Especially in the case of internal projects we see that statements like: "we want to monitor servers Theo van Stratum Page 37 19/03/2006 Why is it that Internal Project Management mostly fails? on the network, you know what I mean" as starting point for a project are common. Those statements are then normally followed with; "how long do you think it will take?" expecting to get a deadline for this project. The biggest problem the project manager faces is that management is expecting that he comes with a real estimate for this project but realistically he cannot even start the user requirements gathering because of no goal at all. Christopher Duncan describes in his book "The Career Programmer! (2002) how a beginner in project management can deal with this behaviour, and I feel that it is a must to read if you are coming from a programmer's career into project management. The first thing a project manager should do if faced with this problem is buy himself some time to write a project description as he understand it and use this as a project proposal. In reality he is leading the project as project owner. This project proposal is presented to management and on which they have to sign-off. The document will go through a number of iterations before everybody agree on the content and the time that is put in to this is not lost, although management will think this, but time invested in this will pay itself back. If consensus about the project description is reach the project manager needs to make a choice in project method; waterfall or agile. Waterfall method In the research we saw that the waterfall method is still the most used, but is it the best for the project underhand? In his 1970 paper, Royce proposed what is now popularly referred to as the waterfall model as an initial concept, a model which he argued was flawed. His paper then explored how the initial model could be developed into an iterative model, with feedback from each phase influencing previous phases, similar to many methods used widely and highly regarded by many today. Ironically, it is only the initial model that received notice; his own criticism of this initial model has been largely ignored. The "waterfall model" quickly came to refer not to Royce's final, iterative design, but rather to his purely Theo van Stratum Page 38 19/03/2006 Why is it that Internal Project Management mostly fails? sequentially ordered model. This paper will use this popular meaning of the phrase waterfall model. Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of the "waterfall model" as a purely sequential process is still popular, and, for some, the phrase "waterfall model" has since come to refer to any approach to software creation which is seen as inflexible and non- iterative. Those who use the phrase waterfall model as a general insult for non-iterative models that they dislike usually see the waterfall model itself as naive and unsuitable for a "real world" process. Usage of the waterfall model Figure 13: Waterfall method The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall. In Royce's original waterfall model, the following phases are followed perfectly in order: - Requirements specification - Design - Construction (aka: implementation or coding) - Integration - Testing and debugging (aka: verification) - Installation - Maintenance Theo van Stratum Page 39 19/03/2006 Why is it that Internal Project Management mostly fails? To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes "requirements specification" -- they set in stone the requirements of the software. When and only when the requirements are fully completed, one proceeds to design. The software in question is designed and a "blueprint" is drawn for implementers (coders) to follow -- this design should be a plan for implementing the requirements given. When and only when the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated. After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs. Thus the waterfall model maintains that one should move to a phase only when it's preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process. Arguments for the waterfall model Time spent early on in software production can lead to greater economy later on in the software lifecycle; that is, it has been shown many times that a bug found in the early stages of the production lifecycle (such as requirements specification or design) is more economical (cheaper in terms of money, effort and time) to fix than the same bug found later on in the process. This should be obvious to some people; if a program design is impossible to implement, it is easier to fix the design at the design stage then to realize months down the track when program components are being integrated that all the work done so far has to be scrapped because of a broken design. Theo van Stratum Page 40 19/03/2006 Why is it that Internal Project Management mostly fails? This is the central idea behind Big Design Up Front (BDUF) and the waterfall model - time spent early on making sure that requirements and design are absolutely correct is very useful in economic terms (it will save you much time and effort later). Thus, the thinking of those who follow the waterfall process goes, one should make sure that each phase is 100% complete and absolutely correct before proceeding to the next phase of program creation. Program requirements should be set in stone before design is started (otherwise work put into a design based on "incorrect" requirements is wasted); the programs design should be perfect before people begin work on implementing the design (otherwise they are implementing the "wrong" design and their work is wasted), etcetera. A further argument for the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as source code. More "agile" methodologies can de-emphasize documentation in favor of producing working code - documentation however can be useful as a "partial deliverable" should a project not run far enough to produce any substantial amounts of source code (allowing the project to be resumed at a later date). An argument against agile development methods, and thus partly in favor of the waterfall model, is that in agile methods project knowledge is stored mentally by team members. Should team members leave, this knowledge is lost, and substantial loss of project knowledge may be difficult for a project to recover from. Should a fully working design document be present (as is the intent of Big Design Up Front and the waterfall model) new team members or even entirely new teams should theoretically be able to bring themselves "up to speed" by reading the documents themselves. However it should be noted that agile methods do attempt to compensate for this: for example, extreme programming (XP) advises that project team members should be "rotated" through sections of work in order to familiarize all members with all sections of the project (allowing individual members to leave without carrying important knowledge with them). Theo van Stratum Page 41 19/03/2006 Why is it that Internal Project Management mostly fails? As well as the above, some prefer the waterfall model for its simple and arguably more disciplined approach. Rather than what the waterfall adherent sees as "chaos" the waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable "phases" and is thus easy to understand; it also provides easily mark-able "milestones" in the development process. It is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and courses. It is argued that the waterfall model and Big Design Up Front in general can be suited to software projects which are stable (especially with unchanging requirements) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started. The waterfall model also requires that implementers follow the well made, complete design accurately, ensuring that the integration of the system proceeds smoothly. The waterfall model is widely used, including by such large software development houses as those employed by the US air force, the US Department of Defense and NASA, and upon many large government projects Steve McConnell sees the two big advantages of the pure waterfall model as producing a "highly reliable system" and one with a "large growth envelope", but rates it as poor on all other fronts. On the other hand, he views any of several modified waterfall models (described below) as preserving these advantages while also rating as "fair to excellent" on "working with poorly understood requirements" or "poorly understood architecture" and "providing management with progress visibility", and rating as "fair" on "managing risks", being able to "be constrained to a predefined schedule", "allowing for midcourse corrections", and "providing customer with progress visibility". The only criterion on which he rates a modified waterfall as poor is that it requires sophistication from management and developers. (Rapid Development, 156) Theo van Stratum Page 42 19/03/2006 Why is it that Internal Project Management mostly fails? Criticism of the waterfall model The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them (or at least, the belief that this is impossible for any non-trivial program). For example clients may not be aware of exactly what requirements they want before they see a working prototype and can comment upon it - they may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested into "Big Design Up Front". (Thus methods opposed to the naive waterfall model, such as those used in Agile software development advocate less reliance on a fixed, static requirements document or design document). Designers may not (or more likely, can not) be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and which does not account for the newly discovered problem areas. Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) refers to design as a "wicked problem" - a problem whose requirements and limitations cannot be entirely known before completion. The implication is that it is impossible to get one phase of software development "perfected" before time is spent in "reconnaissance" working out exactly where and what the big problems are. "Many of the [systems] details only become known to us as we progress in the [systems] implementation. Some of the things that we learn invalidate our design and we must backtrack." McConnell, Steve (2004) Theo van Stratum Page 43 19/03/2006 Why is it that Internal Project Management mostly fails? The idea behind the waterfall model may be "measure twice; cut once", and those opposed to the waterfall model argue that this idea tends to fall apart when the problem being measured is constantly changing due to requirement modifications and new realizations about the problem itself. The idea behind those who object to the waterfall model may be "time spent in reconnaissance is seldom wasted". In summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as follows: Many software projects must be open to change due to external factors; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases. Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it. That is, feedback from following phases is needed to complete "preceding" phases satisfactorily. For example, the design phase may need feedback from the implementation phase to identify problem design areas. The counter-argument for the waterfall model is that experienced designers may have worked on similar systems before, and so may be able to accurately predict problem areas without time spent prototyping and implementing. Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Constant "prototype design" work is needed to ensure that requirements are non-contradictory and possible to fulfill; constant implementation is needed to find problem areas and inform the design process; constant integration and verification of tbe Theo van Stratum Page 44 19/03/2006 Why is it that Internal Project Management mostly fails? implemented code is necessary to ensure that implementation remains on track. The counter-argument for the waterfall model here is that constant implementation and testing to validate the design and requirements is only needed if the introduction of bugs is likely to be a problem. Users of the waterfall model may argue that if designers (etcetera) follow a disciplined process and do not make mistakes that there is no need for constant work in subsequent phases to validate the preceding phases. Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client. It is difficult to estimate time and cost for each phase of the development process without doing some "recon" work in that phase, unless those estimating time and cost are highly experienced with the type of software product in question. The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself. Only a certain amount of team members will be qualified for each phase; thus to have "code monkeys" who are only useful for implementation work do nothing while designers "perfect" the design is a waste of resources. A counter-argument to this is that "multi-skilled" software engineers should be hired over "specialized" staff anyway. Agile Method Most agile methods attempt to minimize risk by developing software in short time boxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While Theo van Stratum Page 45 19/03/2006 Why is it that Internal Project Management mostly fails? iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities. Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish software. At a minimum, this includes programmers and their "customers." (Customers are the people who define the product. They may be product managers, business analysts, or actual customers.) The bullpen may also include testers, interaction designers, technical writers, and managers. Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined hacking (a.k.a. Cowboy coding). Theo van Stratum Page 46 19/03/2006 Why is it that Internal Project Management mostly fails? The Agile Manifesto Agile methodologies are a family of methodologies, not a single approach to software development. In 2001, 17 prominent figures in the field of agile development (then called "light-weight methodologies") came together at the Snowbird ski resort in Utah to discuss the unifying theme of their methodologies. They created the Agile Manifesto, widely regarded as the canonical definition of agile development. "Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more." Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, � 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. The Agile Manifesto is accompanied by the Principles behind the Agile Manifesto, a complete list of agile principles. Theo van Stratum Page 47 19/03/2006 Why is it that Internal Project Management mostly fails? Comparison with other types of methodologies Agile methods are often characterized as being at the opposite end of a spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined." A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive." Agile methods exist on the "adaptive" side of this continuum. <--Agile--> <--Iterative--> <--Waterfall--> <--------\|----------------\|-------------------\|-----> Adaptive Predictive Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the vaguer an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost. Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered. Theo van Stratum Page 48 19/03/2006 Why is it that Internal Project Management mostly fails? When to use agile methods Agile development has been widely documented as working well for small (<10 developers) collocated teams. Agile development is particularly indicated for teams facing unpredictable or rapidly changing requirements. While there are experience reports of teams succeeding with agile development outside of these parameters, there are too few experiences reported as of April 2005 to draw firm conclusions. Agile development's applicability to the following scenarios is open to question: - Large scale development efforts (>20 developers) - Distributed development efforts (non-collocated teams) - Mission- and life-critical efforts - Command-and-control company cultures Boehm and Turner's risk-based approach Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods. The authors suggest that each side of the continuum has its own home ground: Agile home ground: - Low criticality - Senior developers - High requirements change - Small number of developers - Culture that thrives on chaos Plan-driven home ground: - High criticality - Junior developers - Low requirements change - Large number of developers - Culture that demands order Theo van Stratum Page 49 19/03/2006 Why is it that Internal Project Management mostly fails? By analyzing the project against these home grounds, the risk of using an agile or plan-driven method can be determined. Criticism on the Agile Method Agile development is sometimes criticized as cowboy coding. Extreme Programming initial buzz and controversial tenets, such as pair programming and continuous design, have attracted particular criticism, such as McBreen and Boehm and Turner. In particular, Extreme Programming is reviewed and critiqued by Matt Stephens' Extreme Programming Refactored. Criticisms include charges that agile development: - fails to provide an adequate level of structure and necessary documentation - only works with senior-level developers - incorporates insufficient software design - requires too much cultural change to adopt What choice to make? This is depending on team that is led. If the project manager has a programmers back-ground then the Agile method would be more appropriate, as I feel that each software engineering project should be run, but if the project manager doesn't have the right background that this could be difficult. Theo van Stratum Page 50 19/03/2006 Why is it that Internal Project Management mostly fails? Chapter 6: Conclusion Looking at the overall outcome of the research then we are noticing that there is no single solution this problem. In general the problem lies in experience of the project manager. We saw that the more experience project manager is using project management methods to help him steering and managing his project, the stakeholders, and project team; whilst the less experience project manager the project leads without these tools. Due to the fact that most of the less experience project managers is not using a proper project manager method could lead to: - Not properly estimating the work on hand, - Feature creeping, - Failing to make deadlines. When a project starts the project manager needs to access the work on hand in a way that time, cost, and quality could be correct estimated. This is especially a problem by internal project management. The triangle of constrain tells us that the three parameters of a project: Time, Costs, and Quality cannot be in control of one person (team). Especially first time project managers fall in this trap. Instead of being able to do a proper assessment they are told what the project needs to accomplish (quality), when it needs to be ready (time) and how must they can to spend (cost). In other words he is in no control whatsoever. If they are lucky then there is a functional description of the project goal, but more often that is not the case. With this comes the second problem: Feature creeping: During the project user expectations changes and that is normal, if it is done under controlled circumstances (change management) and forces within the triangle of constrain are managed. But more often the project manager gets Theo van Stratum Page 51 19/03/2006 Why is it that Internal Project Management mostly fails? changes, with the comment: "cost only a few hours to do", and none of the parameters are changed with it. This makes that a project fails. The more experience project manager recognises this and will handle accordingly to get the project in control by introducing a proper functional specification, signed-off by the stakeholders, and change management to handle the changes on the functional specification. This last part is more of a problem if the project is handled according the "Waterfall" method as it is by the "Agile" method. Remember that feature creeping isn't a big thing in the "Agile" method due to the fact that the end- users, stake-holders and project members are involved in the each stage and decide together what are the features included. The time line is not altered but features will. What we further discovered was that in internal projects the project manager is, in general, not in control of the resources assigned to the project. Most of the times they are taken from other work within the company and have still work in their "old" departments. This generates a conflict of interest in the sense that their loyalty lies with their workplace, after the project they need to go back. As soon as there are "problems" or colleagues asking for help they could abandon their work on the project, or in worse cases their manager could take them of the project, just for a few days. This endangers the project in a way that is not traceable and reflects on the project manager. So why does it seems to be that those problems not, or less, occur in projects led by an external project managers? It seems that this is due to two things: 1. Experience 2. Authority Theo van Stratum Page 52 19/03/2006 Why is it that Internal Project Management mostly fails? As discussed before: the external project manager is "normally" longer in his profession and has more experience in leading bigger projects, they "see" problems arising before they are happening and react pro-active towards them. But besides that there seems to be a more important "skill" that an external project manager has: authority. Generally spoken: the external project manager gets, as a specialist, the responsibility and authority to handle all things concern the project, including the hire of resources. Because the project manager is seen as an expert he has the ear of the board of directors and much of the problems, the internal project manager has, disappear. Most of the time the project, done by external project managers has the highest priority in the company, whilst projects done by internal project leader are lower on the list of priorities. As I have noticed during the interviews, the internal project manager gets the responsibility but not the authority, which makes it difficult when decisions need to be made and office politics starts to kick in. Theo van Stratum Page 53 19/03/2006 Why is it that Internal Project Management mostly fails? Communication lines Board Internal Project Project team Manager Departments Figure 14: Communication Internal PM Figure 14 shows the communication lines a internal project manager has to deal with and we see here that this should be of great concern. Not only flows the communication between the project manager, the Board, project team, and departments but also between the individual objects themselves with the biggest problem that this bypasses the project manager who starts loosing control. Board Departments Project Manager Project team Figure 15 Communications External PM Theo van Stratum Page 54 19/03/2006 Why is it that Internal Project Management mostly fails? In figure 15 we see the more structural project management approach, which is normally implemented with external project management with the project manager in the middle. This doesn't imply that the Board and Department are not talking with the project team member but there are no decisions made without the project manager. How to avoid the failing of internal projects? (Recommendations) To avoid the failing of internal projects due to the causes found in the research is not easy. It demands a cultural change in the managing of companies, which start with training for the internal project manager. The problem with this is that making the choice to go for an internal project manager most of the time is made to save costs, the salary of the project manager is already a cost for the company (and most of the time NOT calculated in the project costs). This means that we must get a budget for training, not only the project manager but also the project team, if only in training in new techniques for the project. This is something that is mostly forgotten or not in the budget. We must however keep in mind that those cost will result in a better change in finishing the project and the trained project manager could be used in other projects what will spread the cost. Further needs "normal" management hand over the authority over the project resources to the project manager and not interfere by taken resources back, even for a short time without adjusting the project deliverables (triangle of constrain). Management needs to tread the internal project manager, as was he external, with all the responsibilities and authority. Especially for fresh starting project managers coaching would be a good alternative. An experience project manager coached the junior project manager through the project, learning on the job. This could be a hired or internal project manager, but we must take in consideration that the coach needs to have a minimal 6 years of project management experience in the area the project. Especially in the start-up of the project this would be valuable Theo van Stratum Page 55 19/03/2006 Why is it that Internal Project Management mostly fails? in the sense that the coach forces the junior project manager in the use of a methodology and helps with writing the first drafts of the project goal document and functional specification. After that first period a bi-weekly meeting between the coach and project manager would be enough, depending on the project size. Choosing the right methodology is crucial, especially in software development projects. As stated before we have two main lines: Waterfall and Agile development methods. With all the pro and cons regarding the two methodologies I tend to favour for the Agile methodology especially when the project manager is from the development field, which with most of the starting project manager is the case. The research revealed that more then 90% of the internal project managers are the more senior developer promoted to do this job. Waterfall could still be used in smaller, sort term projects. The main reason for this is, as discussed, that in long term projects, functional specifications and user requirements could become out of date due to several changes, ex � and internal. Get from day one change management in place! This is not only for development task but for everything that has to do with the project: Documentation, User Requirements, Functional, and Technical specifications. Make sure that everything done is traceable. By making this a habit the project manager can make sure that there are no questions during the project. Last but not least we have the point of quality. To measure quality we must have a non-ambiguous User Requirements document with the applied change documents. This together is what the goal for the project is. User Acceptance Testing can prove that what is build is in the documentation and on correct the working of it. This means that the project manager needs to make sure that the appropriate test reports are made before the testing begins. Those report are a combined User Requirements, Change documentation and users manual. In the last document are the operating steps noted, and needs to be used as test document. Theo van Stratum Page 56 19/03/2006 Why is it that Internal Project Management mostly fails? Final statement: Project Management is a hectic profession and needs to be managed from the start: Time, Costs, and Quality are the basic parameters that measure a project on success and failing. By applying the recommendations the project manager makes sure that he or she is in control of those parameters and not the other way around. This makes his way to a successful project possible. Theo van Stratum Page 57 19/03/2006 Why is it that Internal Project Management mostly fails? This page is intentionally left blank Theo van Stratum Page 58 19/03/2006 Why is it that Internal Project Management mostly fails? References - Adler, P. A. & Adler, P. (1987). Membership roles in field research. Sage, Newbury Park, CA:. - Beck, Kent.(1999) Extreme Programming Explained: Embrace Change. Addison-Wesley, Boston. - Boehm, B. and Turner, R. (2004), Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, Boston. - Brooks, Frederick P. (2004), The Mythical Man-Month, Addison- Wesley, Boston, USA - Bruce, Andy et al (2000), Project Management, Dorling Kindersley, Londen - DeWalt, K. M. & DeWalt, B. R. (2002). Participant observation. AltaMira Press , Walnut Creek, CA:. - Duncan, Christopher. (2002), The Career Programmer, Apr�s, Berkeley, CA - Fowler, Martin.( 2001) Is Design Dead?. (Appeared in Extreme Programming Explained), G. Succi and M. Marchesi, ed., Addison- Wesley, Boston.. - Giddens, A. (1990). The consequences of modernity. Stanford University Press, Stanford, CA:. - Malinowski, B. (1922/1961). Argonauts of the Western Pacific. E. P. Dutton, New York:. - McConnell, Steve (2004). Code Complete, 2nd edition, Microsoft Press. - McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules, Microsoft Press - Newton, Richard. (2005), The Project Manager: Mastering the Art of Delivery, Financial Times Prentice Hall, Indiana, USA - Stephens M., Rosenberg D..( 2003) Extreme Programming Refactored: The Case Against XP. Apress L.P., Berkeley, California. - Wolcott, H. F. (1995). The art of fieldwork. AltaMira Press, Walnut Creek, CA:. - Wolcott, H. F. (1999). Ethnography: A way of seeing. AltaMira Press, Walnut Creek, CA:. Theo van Stratum Page 59 19/03/2006
	dd