One of the main reasons that projects exist is because of how well the concept fits into helping businesses meet their strategic goals and to respond to current business conditions. Quite honestly, business strategy and project management go hand in hand. Businesses today are forced to be much more agile than they were 30-40 years ago. Business have to deal with a climate that includes shorten product life cycles, increasing technical capabilities, agile competition, all of which make it a necessity to be much more competitive and agile in order to meet that competition and serve customer needs (Cleland 1998)

Today’s Business Climate
In today’s business climate business has to be able to organize a group that can solely concentrate on one objective that meets a business’s strategic goal or need. “Projects are the means for achieving strategic goals. Entering new markets, driving down costs, delivering innovation— all are achieved through projects (Verzuh 2011)”. What businesses have to do is to carefully determine all they can do with the available resources they have.

This means they have to have a steering committee, made of management and stakeholders who have skin in the game, who make the decisions on which projects will be approved. They will base their decisions on how the proposed project fits into the company strategy. They will ask “how well does the proposed project utilize the available resources and at what cost? Which project is going to get us the most bang for our buck?”

Project Portfolio Management
I have worked for companies where “Project Portfolio Management (PPM)” (Verzuh 2011) was handled quite successfully. “It ensures that projects and programs promote organizational strategies and goals” (Verzuh 2011). I’ve worked for some where it wasn’t handled as well and you ran into a Vice-President’s pet project that would suck away all of the resources you thought were committed to your project. The object of the PPM is to ensure that only those projects that move the company towards its stated strategic objective shall be approved. PPM “accomplishes that by avoiding the common trap of trying to do all projects in the midst of limited resources. It requires disciplined decisions driven by agreed-upon priorities.” (Verzuh 2011)

But PPM cannot work if it isn’t organized correctly and the company is not dedicated to adhering to its principles. PPM can bring a balanced portfolio of projects that help a business to achieve its strategic goals while delivering the highest return on its investment.

It’s much like changing from Waterfall as a project methodology to Agile as a methodology. If you’re not fully dedicated to it then it won’t work.
At Walgreens we use a hybrid system that continually needs tweaking. They have a project intake group that reviews the submitted project idea forms. The project idea is reviewed by the Intake Steering Committee made up of the directors of the various team divisions from within the BSS Retail Group. They determine if the project fits into the business strategy and in what way it fits (does it add value or is it a fix). Once the committee approves the project for further review it is assigned to a Project Manager. The project proceeds to identify all impacted teams and develops all the supporting documentation including a high level business requirements document, the project charter, a high level functional requirements document, and what we call an E0 ROM budget estimation (+/_50%). The business requesting the project, and the Intake Steering committee, use the information gathered by the Project Manager to make a determination on the project.

Conclusion
Ultimately, a company that doesn’t develop some kind of process in which to review and approve projects stands losing because it will have wasted resources, time, and money. That business will ultimately find itself out of business as much better organized businesses that understand the value of PPM will beat them to market.

References:
Verzuh, Eric (2011-11-03). The Fast Forward MBA in Project Management (Kindle Locations 9926-9927). Wiley. Kindle Edition.
Cleland, D. I. (1998). Strategic project management. In J. K. Pinto (Ed.), The Project Management Institute Project Management Handbook (pp. 27-54). San Francisco:          Jossey-Bass.

Jack S. Duggal, MBA, PMP in his article “Next Level Up: How Do You Measure Project Success? Rethinking the Triple Constraint” (PMI Community Posts, 9 July 2010) poses the question of whether a Project Manager feels trapped by the traditional triple constraint of Scope, Time, and Cost? Mr. Duggal thinks we need to look at the whole concept differently, especially in light of companies demanding that projects fit into the strategic goals of the company. We need to redefine the definition of success:
“Projects that are delivered on time, within budget and meet scope specifications may not necessarily perceived to be successful by key stakeholders.” (Duggal, PMI Community Posts, 9 July 2010)

Other criteria for project success
Mr. Duggal proposes that project managers need to take into consideration other criteria for measuring progress success. In a survey conducted by the “Projectize Group” in 2008-09 project stakeholders listed such things stakeholder satisfaction, meeting business objectives, customer/end-user acceptance, quality, and benefits as being necessary to determining project success.
“An important concept to understand is that time, cost and scope are related to project outputs, whereas the other factors are related to business outcomes.” (Duggal, PMI Community Posts, 9 July 2010)

I agree that ultimately business outcomes along with strategic goals is what drives projects, it is the job of the project manager to ensure that the project stays aligned with those business goals by using the iron triangle effectively. By controlling scope, time, and costs, the project manager can bring the project to a successful conclusion while meeting the strategic goals of the business.

Fitting the “Other” criteria into the Triple Constraint
Stakeholder satisfaction can be met through a clearly defined project scope. In the scope the object and the goals of the project need to be clearly defined to meet the expectations of the business and the stakeholders. Ultimately they are the ones who approve the scope of the project. The project manager needs to ensure that the scope defines how the object of the project will be met. He needs to ask and get answered the question of what is the purpose of the project: What need or problem is the project supposed to fulfil or solve? What business outcome is the end result?

I see the definition of the scope as the first means by which the team begins to make the connection between the stated business goal and the means by which to achieve that goal. One of the tools that incorporate the scope is the project plan, including the Work Breakdown Structure (WBS). In the WBS the project team defines the work needed to achieve the business goal. It breaks the work down into manageable work packages, sometimes referred to as activities. The duration of time it takes to perform these work packages is estimated which ultimately leads to our budget. The stakeholders will have to review and approve the schedule that gets produced after the WBS is completed. All this activity brings a greater understanding of the strategic business goal the project is helping the business to achieve.

Mr. Duggal suggests that we “mirror outputs with business outcomes”:
“While focusing on each of the triple constraints, the project manager has to reflect and make project decisions based on the achievement of the corresponding business outcome. Cost and time focus has to optimize business benefits like ROI, NPV, etc.,” (Duggal, PMI Community Posts, 9 July 2010)

He feels that user acceptance in the end has to be the ultimate goal of the project. I agree because ultimately user acceptance has to be achieved in order to bring the project to a successful conclusion. In order to optimize ROI and NPV the project has to successfully meet a business need, a corresponding business outcome. After all, why else would we be performing the project if not to meet a business goal? In my own experience I have noticed that when you have a clearly defined scope you get better performance from your team. The team doesn’t like to do work that has no positive meaning.

Parallel Balance
Mr. Duggal suggests using a parallelogram, rather than a triangle, as a way to view managing the contending forces that pull at a project. Each side of the parallelogram would represent the following:
1. Budget
2. Scope
3. Schedule
4. Business benefits/outcomes

The Project Manager would balance budget with scope and schedule or scope with schedule and budget. Business benefits could include strategic goals, user acceptance, and customer satisfaction.

Diamond of Opportunity
The diamond of opportunity looks at tactical project outputs with strategic business outcomes. In other words, does the project align with the expected outcome; are we getting what we’re asking for. Mr. Duggal feels that multiple sides of the diamond help the project manager include multiple levels of focus that may be relevant to the business.

Conclusion
I think that Mr. Duggal ideas carry merit due to the importance of user acceptance of the projects output. The project has to meet the business needs or solve a problem otherwise it has no real reason to exist. But I also feel that the traditional triple constraint iron triangle effectively incorporates the desires of the business because it forces the team to focus on what is really necessary to achieve the goal.

References:
1. Duggal, J. (2010-09-10). Next Level Up: How Do You Measure Project Success? Rethinking the Triple Constraint. Issue of PMI Community Post

It must be understood that the primary responsibility of a project manager is to lead – all the stakeholders, the customers, management, vendors, and project team— and encourage them to work together during the course of the project.

Estimating duration in a project is a daunting task that is usually a best guestimate based on past history. If everyone worked eight hours per day, which is usual in the U.S., but not in India (usually a 9 hour day), and they were 100% productive for all eight hours, you could calculate duration by taking the number of effort hours, divided by the number of resources. So, if one person is assigned a task activity that is estimated at 80 hours, and she works eight hours per day, the duration would be (80 hours / 8 hours per day) = 10 days. Similarly, if four people are assigned to the same task activity full time, the duration would be divided by 4 giving you 2.5 days (10 days/4 = 2.5 days).
However, no one really works a perfect 8 or 9 hours. Our work day is generally broken up into pieces in which other activities such as answering emails, lunch, meetings, other assigned activities, etc. A better estimate would use the 80-20 rule in which 20% of a resources time is eaten up by activities not related to the assigned work. Therefore, I would suggest using the following process to determine duration:
1. Estimate the productive hours per day
A rule of thumb I was taught is using a factor of 6.5 productive hours per day helps you take into consideration those other activities such as answering emails, lunch, meetings, other assigned activities, etc. Using the above example we find our answer for an activity estimated at 80 hours / 6.5 hours = 13 days for one resource, while four resources would take 3 days.
2. Determine the number of resources needed for each activity
Knowing that the more resources you apply to activities, the earlier you can complete the activities, obviously two resources may be able to finish an activity faster than one person, but it may not necessarily be twice as fast. At some point, additional resources will not make the activity finish any sooner, and could possibly, make it go longer.
3. Determine available workdays
You need to take into account holidays, vacations and training, especially when using international resources. This was not included in the example from number one above, since this non-project time can be scheduled and accounted for in advance. On a twelve-month project, team members will be out for vacation days, holidays (US and international) will need to be accounted for in your schedule. To make your schedule more accurate, take into account any days that you know your team will not be available to work on the project.
4. Determine resource time allocation
Account for any resources that are not full time. Keep in mind that a resource whose allocated only 50% of his time to your project will take twice as long to do any individual activity. Using our previous example, you have an activity that has an estimated effort of 80 hours, and you assign a resource that is only allocated 50% to your project, the resulting duration will be at least 25 days for one resource, if not more. For four resources our duration would be 7 days.
5. Calculate delays and lag-times
Some activities have a small number of effort hours, but a long duration. For instance, a deliverable approval may take one hour, but might take two weeks to schedule the meeting.
6. Determine constraints
When building your schedule, identify the tasks that need to be done sequentially and those that can be done in parallel. If you have enough resources, all of the parallel activities can be done in parallel, but only if you have the right resources available at the right time. You may have activities that can be be done in parallel, but you have only one resource to them, thus they have to be done sequentially.
7. Document assumptions
Most importantly, you will never know all the details of a project. As such, it is important to document all the assumptions you are making along with the estimate. The more you communicate with your stakeholders on how you arrived at your conclusions, the better able they will understand your plan and be more willing to accept it.

Using the above suggestions should help make estimating durations for your projects much easier.