Determining the success of a software project is mentioned to be problematic in literature due to different parameters considered by different stakeholders (Ghazi, et al., 2014; Patanakul, et al., 2010; Savolainen, et al., 2012). The authors of “Looking for the Holy Grail of Software Development” (Ghazi, et al., 2014) state that in projects that were deemed as successful by an inclusive list of said parameters, 23% of contribution to success was through project planning and scheduling done with stakeholder involvement. To complement this number, the authors state that 36% of those projects considered successful were considered so because they achieved their scheduling and cost goals. Although these numbers alone are not enough to assert its significance, they present project scheduling and planning as a dual-purpose attribute in consideration with project success, contribution of which seems worth investigation.
Even though it was established that achieving scheduling goals is universally important to stakeholders who has marginally different perspectives (Ghazi, et al., 2014; Savolainen, et al., 2012), the same difference of stakeholder perspectives demands a sophisticated approach in project planning. In a journal forum discussing this aspect (Crawford, 2000), multiple writers express their concerns in unrealistic remarks of published authors about achieving perfect project plans. They address the issue that even if the development team could produce a feasible project plan which is highly unrealistic due to lack of information at the time, customer and upper management alike will have different opinions on project schedule. In most occasions, this would lead to stakeholders enforcing a schedule that is desirable but not even remotely feasible.
“Who” is planning and scheduling the project is another significant concern (Crawford, 2000; Joslin & Muller, 2015). In the absence of personnel to represent the project as the isolated entity it is, by intention or by availability constraints, scheduling of a software project could fall into the wrong hands due to internal politics of the organization (Joslin & Muller, 2015). A project could be of differing importance for each department in the supplier organization and their schedules could prioritize represent their respective departmental objectives. Their unrealistic estimations could lead to customer dissatisfaction and eventual project failure. While project planning should thrive to provide benefits for all departments, it should be not be used as an instrument that supports departmental objectives. The lack of development expertise of planner could also warrant project failure. While project management as a process does not require this knowledge, knowledge of technological restrictions can be necessary in preparing realistic estimates. (Crawford, 2000)
Developer concerns should be addressed in project planning. Developers should not be pressured to make deadlines at all costs, neither should they be given indefinite timelines to achieve a particular goal. However, developer inputs in schedule making are known to be unreliable and contribute towards project failure. This is a co-dependent scenario, where developer input is acquired for already schedule stressed projects that does not have information available elsewhere for estimates while their optimistic estimates exaggerated by lack of planning experience makes the condition even worse (Dvir, et al., 2001). Inferring from personal experience, developer productivity measurement would depend on their job satisfaction which can be seen to vary with the nature of the task. While their concerns should be addressed, developers are usually considered bad sources for time estimates. Conversely, project manager inputs can be seen to contribute towards successful project planning due to experience, objective view on team productivity and ability to gather correct requirements, and is guaranteed to ensure chances of success with feasible schedules (Dvir, et al., 2001).
Plans should not be set in stone when success is concerned. “Inflexible project plans” are known to be counterproductive and common in failed projects. (Dvir & Lechler, 2003; Silva, et al., 2015). Detailed plans are known to be failure prone, as they are unrealistic to be achieved and are rendered useless in light of new requirements at later development phases. Trying to control every aspect can be harmful as it can hinder the creativity and suppress inspirations for using easier or better alternatives. Unfortunately, innovativeness is usually only applied as a backup strategy to be used when projects have fallen behind, (Dvir, et al., 2001) which would be affected by the schedule stress itself and may not be as fruitful.
Even though developer representation and schedule negotiation demands a capable project manager, he alone should not be responsible for enforcing these practices. Support of upper management must be ensured in carrying out these processes (Yeo, 2002).
(Note: Project phases are not considered as phases limited by time by rather sections of software development life cycle, which may be scheduled at different times depending on management methodology used. Waterfall, Spiral, Agile, etc. )
Even though project planning and scheduling occurs during initiation and optimally adapts to changes during the project life cycle, its contribution towards project success cannot be ensured by perceiving it in isolation. Despite having every requirement for successful execution, a project phase could still be stressed by schedule pressure, harming their contribution towards project success itself. With factors such as risk management, change management, resource management and even cost management, this effect can even be recursive, as their successful execution ensures success of project plans and schedules.
Project plans are affected by technological uncertainty and competitor movements. Everything cannot be predicted and these unknown developments may demand project plan adjustments to secure stakeholder interests. In achieving this, both plan adjustment and risk management must be executed properly because not doing one would render both useless. A similar relationship can be seen regarding project plans and change requests (Dvir & Lechler, 2003).These effects of risk and change management supports the fact that detailed project plans contribute towards project failure.
In a multi-project environment, Resource management must be given due consideration (Yaghootkar & Gil, 2012). Studies indicate that projects that are deemed critical by the upper management due to business opportunities, competitive aspects or prioritizing customers, tend to borrow resources (mainly personnel) from parallel projects. Projects that lend resources fall behind due to disrupted learning curves and absence of critical dependency modules which were to be developed by borrowed personnel while the critical project falls behind due to newcomers spending more time catching up. This eventually creates an unbreakable cycle where every project borrows resources from subsequent projects, eventually leading to collective project failures.
In a multi-project environment, quick-fixes in schedule by the project manager is known to create unnecessary schedule pressure that harm subsequent projects. This is supported by the known anti-pattern of “relying heavily on the superstar” (Silva, et al., 2015). Project managers should be discouraged for applying them rather than rewarded, despite any short-term benefits that were achieved.
Of the many project management tools and methodologies available, only a few are actually used, fewer is considered popular, and even fewer is known to contribute towards project success (Patanakul, et al., 2010). This could be either due to project managers selecting tools depending on their popularity or multiple tools being available to accomplish similar objectives. While popularity is not to be ignored entirely, as it ensures the extensiveness, availability of supporting software, community support and their continuation in future while requiring small learning periods, it should not be exclusively depended on in tool selection. Actual benefits and contributions to project success of given tools must be weighed in. More importantly, proper use of these tools must be done for them to contribute towards project success (Dvir & Lechler, 2003; Patanakul, et al., 2010).
It is suggested that the comprehensive-ness of project management methodology used has significant effect on project success. The methodology must have numerous tools available, even if previously never used, as the challenges or management aspect a new project might represent cannot be predicted (Joslin & Muller, 2015), which is a true concern in a multi-project environment. Supplementing modules could be produced to increase the horizons of the selected methodology.
Critical Path Method (CPM), Project Evaluation and Review Technique (PERT), Graphical Evaluation and Review Technique (GERT), Gantt charts, buffer management (in critical chain project management), Milestone planning, baseline planning, scheduled variance analysis and schedule crashing would be a few tools to name that are used in context with project planning. (Besner & Hobbs, 2012; Joslin & Muller, 2015; Patanakul, et al., 2010).
While communication plan, contingency plan, hierarchical schedule and work breakdown structure (WBS) falls within the project planning parameters, they exceed the scope of time management. Monte Carlo Analysis in risk management, change Requests, scope statements, resource assignment and lessons learned during termination phase are tools that are completely outside the planning scope but still relative to phases that could affect the contribution to success by proper project planning. (Besner & Hobbs, 2012; Patanakul, et al., 2010; Yaghootkar & Gil, 2012).
Critical Path Method has a high contribution towards project success (Patanakul, et al., 2010). This seems to be accurate as keeping track of critical activities and their timely delivery and activity dependencies could give freedom regarding non-critical tasks while not falling behind schedule. Use of “Post-it” notes at the top level and software tools for task management tools at sub-levels is also suggested as CPM predictions could turn out to be inaccurate for complex projects (Dvir & Lechler, 2003). Milestone planning contributes to success a substantial amount (Besner & Hobbs, 2012; Patanakul, et al., 2010) and is in fact highly productive in a developer-friendly environments as it is “result-oriented”, providing order and yet enough freedom to utilize creative thinking and new solutions without worrying about strictly knit schedules (Dvir & Lechler, 2003).
Analogous estimate is known to contribute to project success but it is often unreliable as identical projects may not be available for estimates. But it could be used in a multi-project environment, if accurate tracking of previous development endeavors and historical records is performed in the organization. Similarly, success contribution of Bottom-up estimates is seen to be low due to unavailability of details at planning stage. However, unlike analogous estimates a good communication plan would alter this situation, ensuring accurate estimates that can be pursued.
Gantt charts have a comparatively higher rate of use even though its contribution towards project success is uncertain (Besner & Hobbs, 2012). Despite being mentioned many times, PERT does not seem to contribute to project success and is not widely used. (Besner & Hobbs, 2012; Dvir & Lechler, 2003) Use of PERT is discouraged.
Checklists should be avoided during planning as it is known to discourage employees at a phase where not enough information is available to make useful deliverables. While schedule crashing cannot be held responsible, it has a significant association with failed projects. This can be due to the fact that this is only used on projects that are already behind schedule. Change requests has a similar relationship with communication deficiencies during the planning phase as schedule crashing does with delayed projects (Patanakul, et al., 2010). Baseline plan is frequently used but ironically, the greater use of change requests is seen to cancel out its contribution to project success and cannot be recommended. (Besner & Hobbs, 2012)
Lessons learned is known to nurture development environment and the understanding of organizational context as it can determine what works and what doesn’t and respective adaptation of methodology. Maintaining historical records and scheduled variance analysis is also recommended for supporting accurate analogous estimates and bottom-up estimates in the future.
Phase-restricted tools are more frequently used than tools used throughout the project life cycle. This can be attributed to lasting involvement and organizational support required for their proper use. This could also explain why certain planning tools have less popularity in a multi-project environment compared to normal project environments (Besner & Hobbs, 2012). While utilization of these tools could secure project success, the time and resources required to ensure its comprehensive-ness and training new project managers, can stand as a barrier.
According to the analysis presented above, following guidelines can be recommended in order to achieve accurate project planning and secure its contribution towards project success.
Even though successful execution of project planning and scheduling has the potential to considerably contribute towards project success, optimum project plans is not quite realistic in real life projects. Multiple Numerous criteria must be met to achieve this and even if it was accomplished, uncertainties in future may require plan alteration. (Dvir & Lechler, 2003) One might even successfully argue that project planning is not worth doing in consideration with the success of projects that had free range in its schedules (Crawford, 2000). But being a factor in determining project success, planning cannot so easily be dismissed. Alternatively, this uncertainty can be integrated and planning can be made fruitful by using tools such as milestone planning.
Planning should not be expected to contribute towards project success by itself. Risk, change and resource management must be properly executed to reap collective benefits. Generally speaking, in an environment that require maintaining multiple projects, a comfortable management and development culture enforced through a comprehensive and contextually-appropriate project management methodology could naturally facilitate the proper project planning required and all subsequent project management attributes, eventually ensuring project success.
Besner, C. & Hobbs, B., 2012. An Empirical Identification of Project Management Toolsets and a Comparison Among Project Types. [Online] Project Management Journal, Volume 43, pp. 24 – 46. [Accessed 17 January 2016].
Crawford, D., ed., 2000. Forum – Planning for Software Project Success. [Online] Communications of The ACM, March, Volume 43, pp. 11-14. [Accessed 21 December 2015].
Dvir, D. & Lechler, T., 2003. Plans are nothing, changing plans is everything: the impact of changes on project success. [Online] Research Policy, Volume 32, pp. 1 – 15. [Accessed 20 January 2016].
Dvir, D., Raz, T. & Shenhar, A. J., 2001. An empirical analysis of the relationship between project planning and project success. [Online] International Journal of Project Management, Volume 21, pp. 89 – 95. [Accessed 5 January 2016].
Ghazi, P., Moreno, A. M. & Peters, L., 2014. Looking for the Holy Grail of Software Development. [Online] IEEE Software, 31(1), pp. 96-96. [Accessed 20 December 2015].
Joslin, R. & Muller, R., 2015. Relationships between a project management methodology and project success in different project governance contexts. [Online] International Journal of Project Management, Volume 33, pp. 1377-1392. [Accessed 20 January 2016]
Patanakul, P., Iewwongcharoen, B. & Milosevic, D., 2010. An empirical study on the use of project management tools and techniques across project life-cycle and their impact on project success. [Online]. Journal of General Management, Volume 35, pp. 41 – 65. [Accessed 10 January 2016].
Savolainen, P., Ahonen, J. J. & Richardson, I., 2012. Software development project success and failure from the supplier’s perspective: A systematic literature review. [Online] International Journal of Project Management, Volume 30, pp. 458-469. [Accessed 20 December 2015].
Silva, P., Moreno, A. M. & Peters, L., 2015. Software Project Management: Learning from Our Mistakes [Voice of Evidence]. [Online] IEEE Software, Volume 32, pp. 40-43. [Accessed 21 December 2015].
Verner, J. M., Evanco, W. M. & Cerpa, N., 2007. State of the practice: An exploratory analysis of schedule estimation and software project success prediction. [Online] Information and Software Technology, Volume 49, pp. 181-193. [Accessed 20 Decemeber 2015].
Yaghootkar, K. & Gil, N., 2012. The effects of schedule-driven project management in multi-project environments. [Online] International Journal of Project Management, Volume 30, pp. 127-140. [Accessed 15 January 2016].
Yeo, K. T., 2002. Critical failure factors in information system projects. [Online] International Journal of Project Management, Volume 20, pp. 241 – 246. [Accessed 14 January 2016].