Forecasting Human Resource Needs

Human resource needs are typically the most costly piece of any project. It is especially costly if either over estimated and therefore over compensated for or under accounted for and therefore forcing the project to not meet the desired deadlines. If the later occurs often companies are forced to either push out deadlines or hire in costly outside contractors to force the project back on track with the desired timeline. Either way ultimately undesirable results are experienced. Only when resources are properly accounted for, and budgeted for, does the project team find themselves in a winning position.

There are many methods that are available to assist with the forecasting of these human resource needs. There are two major approaches to forecasting techniques, qualitative and quantitative. Some examples of qualitative approaches to forecasting are estimation techniques, expert opinion, Delphi, and averaging. A few of the possible techniques that could be used with the quantitative approach are trend analysis, regression analysis, simulation techniques, and Markov.

In order to monitor and insure the fulfillment of the human resource requirements, the organization will want to include items such as Performance Reviews. Performance reviews measure, compare, and analyze schedule performance such as actual start and finish dates, percent complete, and remaining duration for the work in progress. (Project Management Institute, 2008, p. 162) During the project completion the Performance Review is used to track the current status of tasks within the project including the completion percentage. Based on the scheduled start and end date and the current completion percentage the schedule variance (SV) and the schedule performance index (SPI) can be calculated. This can be easily completed using a simple spreadsheet within Excel. Project managers use Earned Value Management (EVM) techniques to compare the schedule performance (achieved by getting information from the Performance Review we discussed earlier) and the cost of the performance (what have we spent so far and what will we spend). In short what we are trying to achieve is creating a basic business value for what we spent model. This is often a report or graph that will be provided to the project sponsors before during and after the project completion. The Earned Value (EV) can be compared to actual costs and planned costs to determine project performance and predict future performance trends. (KIDASA Software, 2010) Earned Value shows how far off we are with regards to the budget and time that should have been spent in comparison to the actual amount of work done to date. (Haughey, 2009) Another key term that needs to be discussed with regards to this subject of schedule variance (SV) and schedule performance index (SPI) is that of the Variance Analysis. The SV and the SPI are used to assess how big of a variation we have in comparison to the schedule baseline. (Project Management Institute, 2008)

The Monte Carlo simulation method is a way of simulating ranges of projected needs for project resources, time, etc. In order to complete a Monte Carlo Simulation the project manager will need an application that can reiterate the simulation up to several hundred times. In short all that the project manager needs to do is create a baseline experienced oriented guess on what the resources that will be needed for each task. He or she will need to provide a low value and a high value for the simulation to be addressed. These highs and lows will for each task within the project will be used to produce a high and low value of resources that will be needed for the project. The simulation would then be ran several hundred times in order to increase the accuracy of the estimated values. (, 2010) One application that could be used to perform this is the Risk AMP application. This or course could be used in order to project the human resource needs of the project.

When looking at the human resource needs many other variables will need to be taken into account when discussing international projects with resources located within many disperse countries. One of the biggest variables that needs to be taken into account is the potential for different work hours. Some countries only work 4 days a week, while others may work 6. Some countries take long afternoon breaks and then come back to work during the cooler evening hours. These discrepancies with work schedule must be accounted for and potentially the project manager may need to set different timelines within each country in order to complete the work. Another option for the project manager is to simply look at the number of man hours it will take in order to complete the task and simply within those countries that do not work as much, increase the head count in order to maintain the schedule. This will result still in the same number of man hours. Some countries may also be more productive during the work hours and therefore require less time to achieve the same tasks. For instance many other countries, at least perceive, US employees as people that often stand around the water cooler all day and do not produce well. Again a statistical baseline will need to be created in order to achieve accurate goals and forecasts within the project.

The To-Complete-Cost Performance-Indicator or TCPI is used as an indicator index that shows how efficient the resources working on the project should be used during the remaining time of the project. In order to calculate the TCPI the project manager will need to know the total budget for the project, earned value (discussed previously), and the actual expenditure of resources. In short the TCPI = ( Total Budget – EV ) / ( Total Budget – AC ). (Tutorials Point, 2010) In short, TCPI is used to determine what the project performance that is required to complete project as budgeted.

Haughey, D. (2009). What is Earned Value? Retrieved August 15, 2010, from Project Smart:

KIDASA Software. (2010). What is Earned Value Management? Retrieved August 15, 2010, from Earned Value Management:

Project Management Institute. (2008). A Guide To The Project Management Body of Knowledge. Newtown Square: Project Management Institute, Inc. (2010). What is Monte Carlo Simulation? Retrieved August 14, 2010, from

Tutorials Point. (2010). To Complete Cost Performance Indicator (TCPI). Retrieved August 15, 2010, from Tutorials Point:

Six Software Development Frameworks

Introduction and Background

In software development, there are a variety of software development frameworks available for Innovative Systems’ consideration.  These frameworks abide by a specific life cycle to make sure of the software development’s success.


Waterfall Model

The waterfall model is one type of software development framework.  This was the first model introduced and pursued generally in “software engineering” since 1970 states Parekh (2005).  In the waterfall model, the entire software development process is split into distinct phases.  These phases are: requirements specification, design, implementation, integration, testing, installation and maintenance.  The development advances in sequence through these phases.  Just like in a waterfall, the movement “flows” downward from one phase to another (TechRepublic, 2006).  According to Steele and Swiler (2002), the output of a certain phase serves as the input for the next phase.  In this particular framework, you are only supposed to transfer to a phase when the prior phase is accomplished.  Between these phases, there is no overlap or bouncing back and forth notes Select Business Solutions (2010).

The waterfall model can be classified as a systems development life cycle.  It involves a phased sequence of activities.  According to Bista (2010), there are distinct goals in every phase of development.  This model starts with the requirements analysis of the system.  Then, this leads to the system’s release and later maintenance.



Dynamic system development method (DSDM)

Dynamic system development method (DSDM) is another software development framework which develops software systems dynamically through the use of prototypes.  The framework is basically a variant of the rapid application development method (RAD) process.  According to (2010), its aim is to produce systems according to time and budget while accommodating for revisions in the requirements during system development.  This is practical for systems that call for to be developed in the shortest amount of time and where the goals cannot be stalled at the beginning of the application development.  The following phases are part of DSDM:  feasibility study, business study, functional model iteration, design and build iteration and implementation.


DSDM could be categorized as a mold of the systems development life cycle because it is an in-depth plan of how to build, develop, implement and close the project.  The whole plan outlines how the system is born, raised and later retired from its purpose.


The waterfall model is a non-iterative approach while DSDM is an incremental and iterative approach.  One element of the waterfall model is that the phases cannot start unless the previous phase is completed.  This software development model has to follow the phases in sequence (Select Business Solutions, 2010).  On the other hand, DSDM is the opposite in regards to this.  DSDM allows the project to go back to preceding phases in order improve it and the final product.  When the requirements are continually changing in a project, the DSDM is quick to respond whereas the waterfall model is not appropriate (, 2010).  Both of these frameworks, waterfall model and DSDM, are classified as a systems development life cycle.


Agile Software Development

With Agile Software Development, end user involvement is very critical to the project’s success. In many cases due to the way that Agile development works, this is not possible. However in these cases, you will want to appoint senior-level end users which will represent the majority of the end users that you are trying to satisfy. This way, the smaller projects are prioritized according to what the end users need the most. In order to provide the quick results that are requested of a development team in an agile environment, the team needs to have decision making abilities. In order to accomplish this, you will again want to insure that they have direct contact with the senior-level end users on a day-to- day basis. Where most project management/software development methods try and stake down all requirements upfront with a timeline, the Agile approaches this much differently. The agile method of development works on the idea that the end users do not know what they want until they begin to see, and use, the end product. Based on this philosophy, the developers try and get a base model out to the end users and then the end user evolves the project as they see the need. This provides an end user with a product that they will use, not a product that has extreme functionality but will never be used (Waters, 2007).


With Agile, we want to capture the system requirements at a high level only. This philosophy follows where we last left off in that with Agile, we want to get the minimum requirements the end users want and need. Then, provide them with that one part completed very well. From there, we will focus on the next part or activity. Of course in order to have a good and stable end product, we still need to have an idea of the end target for the project and take every end user request as a direction to lead us towards the end goal. The overall concept of develop small, incremental releases and iterate is one of the main focuses that we are trying to accomplish by using the agile methodology. By doing this, we are reducing risk, increasing value, being more flexible, and providing better cost management. If the project runs out of money and management kills the project, the end users are not left with nothing. In fact, they may be left with a very good product that they may use and the project may be able to be returned to once funds again become available. In other words, with Agile we will want to insure that we complete each feature before we move on to the next enhancement. As such, testing will be completed throughout the full life of the project versus at the tail end of the project once all aspects of the project are complete. Again, communication and collaboration between all stakeholders is essential for this philosophy to work and work well (Waters, 2007).


When comparing Agile to the Waterfall approach, you will find that both use Use Cases and UML diagrams for analysis and design. DSDM is often considered the original agile development method. SCRUM is another agile development method that focuses on managing tasks/activities within a team versus individual developers. XP can also be considered an agile method of development. However, it focuses heavily on the software developments process and is shooting for a high quality en product (Waters, 2007).


The Agile Software Development methodology is a member of the System Development Life Cycle as there is a definitive process of planning, analyzing, designing and implementing each phase of the program as it is developed. Again, the major difference with this framework and other SDLC methods is that this process reiterates many times before the project is ruled complete versus only once. Although Agile is considered a member of the System Development Life Cycle family of frameworks, this should be very clear at this point that many of the concepts could be used with the project life cycle as well. For instance if providing an end user with video conferencing solution, the project manger may want to focus on the 80/20 rule that often focuses on with the Agile method. With the 80/20 rule, we take the philosophy that 80% of the results come from 20% of the efforts. So, we want to focus on the 20% of the efforts that are going to matter. We may want to only implement the pieces of the video conferencing system that are going to matter most to the end users and then grow the project from there as the company adopts the new technology.


Rational Unified Process (RUP)

As different projects have different process needs, the factors that determine these needs usually put the processes into either a formal or an agile process. A Rational Unified Process (RUP) is a Software engineering Process that provides a disciplined approach t software development. Even though this process does rely on some measure of a formal process it does work better with an agile process. This particular process does have the capability to automate certain large portions of the process. RUP acts as a guide when utilizing the unified modeling language (UML). UML does enable the clear communication of architectures requirements, and designs. And as such it can act as a systems life cycle or as a product life cycle in that it can easily handle larger projects which would be either a system (Mainframe), or as a product, (Office 2010). As stated in the first sentence about there being different needs for the various projects, RUP can be easily configured to match many different projects. While each software lifecycles can be broken into different cycles that work of new generations of the product. And each cycle being broken into an iteration (or phase), being; Inception (initiation), Elaboration (planning), Construction (execution), and Transition, (Closing).


The open unified process (OpenUP) uses many of the essential characteristics of RUP, but does not provide guidance on many of the topics that many large projects may work with, that RUP does work with. Topics such as: compliance or contractual situations, large teams, mission critical applications, etcetera. OpenUP is a minimally sufficient process where only the fundamental content is included, (Balduino, 2007). Even though OpenUP is an agile process, it is considered lightweight by comparison to RUP, it does apply iterative and incremental approaches within a structured lifecycle that uses cases, scenarios, risk management and architecture type approach that drives development, (Balduino, 2007).

The four core principles of OpenUP are:

  1. Collaborating in order to align the interests and sharing understanding.
  2. Balance an y competing priorities in order to increase the stakeholders value.
  3. Focusing on the architecture early in order to minimize any risks and to organize development.
  4. Evolve in order to promote activities that obtain feedback from the stakeholders in order to improve the development and to give the stakeholders value.


The activities would be more in line with a product lifecycle in that it does what it can to promote the project/product by promoting a positive environment.



Extreme programming

Extreme programming is a type of agile process that is based on values of simplicity, communication, feedback and courage. It was first introduced in the 1990’s at DeimlerChrysler by Mr. Kent Breck in an attempt to find a better way to develop software, (Copeland, 2001). Originally designed to be flexible enough to freely communicate with the customer and to have the coding of the software change (if needed), to fit with the possibility of the changing requirements. One downside to this is the potential for project creep, which can be disastrous to the budget and schedules. Two forms of planning would be a release planning whereas the customer would state what their requirements are and the developers would estimate what the difficulty would be. Another form would be iteration planning where the developers would be given updated direction every two weeks or so with a tested usable segment ready at the end of that time so that it may test by the customer. Extreme programming has been developed as a lightweight development process, where coding has a continuous integration that takes place from every few hours to approximately a day and then tested, if the test fails, only the unworkable portion is removed and fixed (or discarded, then redone). The way that this process is setup, it has the appearance o being more “flowing” than other methods, for more of a continuous development.


Rapid Application Design (RAD)

There many approaches that the organization may explore when selecting software development frameworks these methods range from spiral models to waterfall models. The development types may include processes such as adaptive software development when a process follows an adaptive approach providing more freedom; or when collaboration is needed may warrant an agile development approach. Utilizing processes such as the RAD lifecycle model uses an approach in which developers are working with an evolving prototype; this lifecycle involves user collaboration which produces systems quickly without sacrificing quality. Rapid Application Development (RAD) methodology allows developers to develop systems strategically in a cost effective manner while preserving quality utilizing proven development techniques. This application process allows the development cycle to be expedited saving valuable resources. Rapid Application Development tools such as; computer aided software engineering (CASE), JRP (joint requirement planning), and JAD (joint application design) to conduct prototyping and code generation (Schwalbe, 2007). The rapid application development process is an example of a predictive lifecycle meaning that the scope of the project can be seen or articulated. This particular lifecycle model is part of a framework known as the system development lifecycle. However, the system development life cycle has elements that are quite similar to project lifecycle development which include; the assigning of project managers to oversee the entire development process and adjusting scope requirements to satisfy time and cost. There are also conditions that may cause project managers to modify traditional project management methods depending on the particular product lifecycle. The RAD lifecycle model is an example of how elements differ from traditional project lifecycles; mainly because a RAD lifecycle may have an existing functioning product that may warrant additional features and upgrades in addition to spending an enormous amount of time on requirement specifications. There are software development frameworks such as Adaptive Software Development model that provides the functionality requirements that is specified by the stakeholders or business group as the needs are discovered in a more liberal approach. The Adaptive Software Development model follows an adaptive approach because requirements cannot be expressed in a clear manner (Schwalbe). In comparisons with other models like the project lifecycle the scope of a project utilizing the Adaptive model differs because its scope can’t be clearly defined initially versus a project lifecycle which the project scope is set initially allowing stakeholders to have clearly defined vision of the type of product or process they will receive. The key aspects of this approach are that projects are component based and mission driven utilizing time based cycles to meet target dates. These types of projects are usually risk versus scope driven as found within a project lifecycle framework.



Overall, the success of the project will depend on how directly Innovative Systems abides by a software development framework.  Innovative systems must be aware that certain software development frameworks will work better than the other frameworks in managing a software development project.  If Innovative Systems correctly executes these frameworks, considerable time and cost savings can be expected. There is not any one hit wonder to software development that will work in every instance. Real results come from project managers with a lot of experience and skill, have knowledge of a lot of different techniques and know when each technique is most appropriate in the right environment to achieve the desired results. Typically, the correct solution is a combination of many different techniques.







Bista, B. (2010).  The Waterfall Model: IT Project Management Solutions. Retrieved June 30,

2010, from (2010). Dynamic System Development Method (DSDM). Retrieved June 30,

2010, from

Parekh, N. (2005). The Waterfall Model Explained. Retrieved June 30, 2010, from

Select Business Solutions. (2010). What is the Waterfall Model? Retrieved June 30, 2010, from

Steele, J. & Swiler. N. (2002). The Software Development Life Cycle (SDLC).  Retrieved June

30, 2010, from

TechRepublic. (2006). Understanding the Pros and Cons of the Waterfall Model of Software

Development. Retrieved June 30, 2010, from


Waters, K. (2007). 10 key principles of agile software development. Retrieved July

1, 2010,from

Kerzner, H. (2009), Project Management: A systems approach to planning, scheduling, and

controlling, (Tenth ed.), Hoboken, N. J., John Wiley & Sons, Inc.

Project Management Institute (2008), A Guide to the Project Management Body of Knowledge

(PMBOK Guide), (Fourth ed.), Newtown Square, PA, Project Management Institute

Project Management Institute (2009), Q & A s for the PMBOK Guide Fourth Edition, Newtown

Square, PA, Project Management Institute

Schwalbe, K. (2007), Information Technology Project Management, (Fifth ed.), Boston, MA,

Thomson Course Technology

Gido, J. & Clements, J. (2006), Successful Project Management, (Third ed.) Mason, OH,

IBM (1998), (rev. 2001), Rational Unified Process: Best Practices for Software Development

Teams, retrieved on 06/29/10 from

Balduino, R. (2007), Introduction to OpenUP (Open Unified Process), retrieved on 06/29/10


Balduino, R. (2006?), Basic Unified Process: A Process for Small and Agile Projects, retrieved

on 06/28/10 from

Wells, D. (2009), Extreme Programming: A Gentle Introduction, retrieved on 06/29/10 from

Wells, D. (2009), The Rules of Extreme Programming, retrieved on 06/29/10 from

Copeland, L. (2001), Extreme Programming, retrieved on 06/30/10 from