How can you identify the resource requirements for a program?

Effective project planning focuses on resources, including people, facilities, funding, equipment, process and more. My systematic approach starts with "Resource planning", to determine the types and quantities of resources required to perform each schedule activity. during this planning phase I use the following approach to effeciently determine the resource requirements: 1-Expert Judgement, their opinions can be invaluable. 2-Alternative Analysis, Often, there’s more than one way to accomplish a task, so you have multiple options. 3-Published Estimating Data. 4-Project Management Software, that include features estimating resource needs and constraints. 5-Bottom-Up Estimating, tends to be very accurate, but it’s time-consuming.

In order to arrive at a good estimate of the resource requirements for a program, we should use brainstorming, tree diagrams and knowledge collaboration of Subject matter experts (SMEs) and Solution Architects. First, the SMEs need to list down all resources that are needed and the estimation techniques to be followed which needs to be selected in their most appropriate manner. All of the information needs to be provided to the Solution architect, who can synthesize it together and review with clients and senior management for reviews and approvals.

Top-down estimation is an approach where project estimates are derived by breaking down the overall project into smaller pieces, and then estimating the resources and time required for each component. While this method has its merits, there are also disadvantages associated with top-down estimation: 1-Lack of Detail 2-Limited Accuracy 3-Risk of Over-Optimism 4-Difficulty in Tracking Progress 5-Risk of Missing Critical Components 6-Challenges in Cost Control 7-Limited Use in Agile Environments

In my experience, I start with a top-down / Delphi based estimation consulting the experts to arrive at a level-1 estimate. This helps me to fix the estimate with a +/- 25-40% variation but also gives a glimpse of all types of resources required (people, facilities, data, server, computing, network, licenses etc.). I follow it with a level-2 estimation after doing a small PoC (Proof of Concept) where possible or doing a WBS. This brings down uncertainty to +/- 25-20%. Finally, when we draw the detailed Gantt chart at a task level (or a release level), we do a level-3 estimate to bring it to +/- 5% variation.

In a college analogy - bottoms up resource management is a 200 level class. The simple part is the by role or by person % utilization needed by unit of time estimation. List resources as rows and units of time as columns, input percentages of utilization into each cell. The real groundwork is done in your data validation and set-up: what are the roles? who is in each role? how many hours do they have to commit to a program vs admin vs "day job" activities. Then you've got to roll that up into a by role forecasting matrix to validate that you, in fact, have the resources available to execute the program during the time period it is scheduled for.

Analogous estimation is quite often used when you are working on multiple engagements for a same client/same solution set for a particular market for a broad range of customers. Here are 6 tips to be effective: ? Multi-project blend: Find several relevant projects, not just one. ? Team insights: Leverage their experience with wins and challenges.Take inputs from them. ? Adapt, don't copy: Fine-tune estimates for your specific needs. ? Iterate and adjust: Be ready to update the plan as you learn. ? Communicate openly: Keep everyone informed and involved. ? Celebrate progress: Focus on delivering value, not just hitting a number.

Always rely on solid numbers. Drill down and reverse engineer the needs versus the wants. Needs first, of course, the wants second, and the goals should add up to the desired state. Leave time for the best in class finale as you cannot go wrong I. Out-performing the competition.

In reality or atleast in most cases, a combination of the top down estimation, bottom up estimation and analogical estimation is used, based in the maturity of the program and context . Likely you'll start with a top down estimation and refine it over time using the other methods.

Start with a statement of work (SOW) that specifies the end goal for a project. Break the SOW into tasks for each element of your organization. Have a bottom-up cost/resource estimate prepared for each task. This should provide a “worst-case” estimate. Senior management then applies a top-down viewpoint, i.e., what projects of similar scope have or (should) cost. In most cases, the resource estimates will be pared down for, reflecting how risk tolerant/adverse management is. The PM should be able to see areas where risk will be highest, and where extra attention needs to be placed. I’m sure that there are other projects types where other methods are more relevant. But my experience has been that the bottom-up/top-down method is sound.

In the context of agile software delivery, you start with top down or analogous estimation and then get to an iterative bottom-up estimation by having the teams doing the work size epics and user stories.