I just started studying for PMP certification.
All the processes mentioned in PMBOK are relevant to all the domains of project management.
But as a leader in I.T projects following are some issues we need to deal with regarding estimations and costs.
1. While estimating we do not know the resources.
2.No two person will have same domain/technical knowledge.
3.While estimating we generally estimate based on our exp., plus some buffer, but actually it depends on developer who will work on task.
4. It also happens that we identify the resource while submitting proposal to client but till the SOW is signed to go ahead, resource is already allocated to other project.
5. Cost of the resource varies hugely.And in I.T sector major chunk of cost is salaries which is not in P.M hand but market driven.
6. If less experienced guys are taken the traning on domain/technical skills is to be done (for this i am sure no client will pay OR will be ready to delay the milestones)
I would like to know what all the experienced P.M in I.T sector has to say on solutions these issues.
Saving Changes...
As you probably know, the PMBOK refers to the broader scope of the Project Management discipline. The issues you listed are specific to IT Project Management. I can't answer all of the issues you listed in one post, but I can say that in similar situations I've produced multiple estimates or "what if" estimates that have helped me at least mitigate risks down the road. The PERT technique can also be expanded to account for more or less technically skilled workers (i.e., the pessimistic estimate ties to a less skilled technician and the optimistic to a higher skilled one). These are all common problems that IT PMs run into, particularly in shops that have little or no PM disciline. Saving Changes...
Robert PennSr. Project ManagerAlexandria, Va, United States
IT projects are often difficult to plan, not only because of the resource issues you identify, but also because scope and requirments are often soft at the time you develop the plan. When you know the skill levels and domain knowledge of your team, you can often give a tighter estimate, but on several occasions, I have had to plan a project where the first task was to source and hire the team who would do the work. The only way to do this effectively is to start with your WBS and identifying the types of skills you need, identify 3 or 4 skill levels within each type category, and use your best judgment.
On most IT development projects, you will need people with business analyst/requirements skills (on a small project, the PM may be able to fill this role), some software developers, probably one or more data specialists, some testing/QA specialists, and maybe some technical writers.
Based on these general skill categories and the tasks identified in yor WBS, you can then consider the levels of expertise needed in each skill category. For example, you will probably want a senior person to provide leadership in each area, some mid-level people to do most of the work under the direction of the lead, and some junior people to handle some of the more routine tasks.
When you actually assemble your team, you will make tradeoffs based on the people available to you. You may end up with 2 senior level people instead of 3 mid-level, or some other deviation from your plan, based on the assumption that a senior person will be more productive than a mid-level person and the cost differential fits within your budget.
Another consideration is when you need each of the skills. If your requirements analysts are also your testers, you need them at the start of the project, but if they are a separate team, you may not need them until near the end. In your planning, you really need to think through how you will do the work so you can have the right people available at the right times and minimize the downtime when people's skills are not needed.
The final thing to remember is that a project plan is your best estimate (guess) about how you will complete the project. You can't know the exact amount of time needed or the budget (both always seem to need more than you planned). While you need to be aware of competitive pressures to keep costs and schedules down, you need to allow buffers for uncertainty because the project will never go exactly as you planned it. Saving Changes...
Jaiveer Singh ChandPM Consultant| The Golden Circle Consulting, SingaporeGreater Noida, Uttar Pradesh, India
In IT industry, most of the project managers have career background as developers in their initial years which give then required skills set to estimate work package size to reasonably good numbers however it is always better to involve atleast 3-4 team members in estimation process.
- Members involved in planning should represent different level of competency of proposed team (Expert, Intermediate, Beginner)
- Estimates should consider PERT Estimation (Optimistic, Most Likely and Pessimistic estimates)
- Project Manager should estimates cost and present it to management for getting budget approvals. PM is accountable to execute project in approved cost budgets. Trainings, Travel, Communication, Team Building & contingency costs all should be included while consolidating project costs to Management.
- PM should also be aware about organisation risk tolerance level, Project Risk Rating, Project priority in organisation, Stakeholders Influencing power and more importantly project constraints sequence (1. Quality, 2.Time & 3. Cost )
Saving Changes...
I think you’ve received good practical advice here from the contributors: (1) having a variety of skilled individuals contribute to the estimating process (if possible), (2) including all the costs and not just the development costs, and (3) realizing that it is difficult to estimate effort at the start of a project, especially if it is a large one.
One technique you might consider is to get approvals through the detailed design phase. This allows for the requirements, analysis, and design phases, which should produce a realistic estimate for the development effort, capital expenditures, traning, implementation costs, travel, etc. In an outsourced environment where there are real dollars involved, this approach makes management more comfortable with approving the expenditure, knowing it is more accurate than the ‘plumb line’ approach. I realize however that this may not be practical in certain staffing situations.
Saving Changes...
George JucanManaging Partner| Organizational Perfomance Enablers NetworkWoodbridge, Ontario, Canada
Amogh, I can certainly relate to your issues as any other IT Project Managers. We've all been there, and with the advice from the other posts I hope you'll get by until you have enough experience (there is no shortcut to "trial and error", but it will get better every time).
Beside the good advice already posted, you may want to check out "Estimation Blues" (http://www.gantthead.com/content/articles/227718.cfm) where I approached some of the issues you're describing. Hope it helps,
First of all thanks very much for all the inputs.
This will help me in some scenarios in future.
I had a typical scenario where
1. Project is a subcontracted. This means our client is executing the project and weare doing part of it.
2.Cllient himself is technically very good so its not easy to give pessimistic or any estimates which covers lot of buffer.
3.Its a fixed cost project.Estimates are to be submitted before the contract is given..
4.. Project pricing is negociated by marketing team and client.So revenue is not in PM's hand.Also main expenditure i.e salaries is not in PM's hand.
So, in a way I feel tied down, as revenue is fixed,expenditure can be managed only by taking people with less salaries or finishing the project with less hours so that no need to keep resources for long run.Add to this curreny fluctuations i.e revenue in one currency and expenditure in other.
So thats why I gave the posting.
I would say from all the contributions, have great efforts put in while estimates. So that risk will be lower.
Saving Changes...
Since fixed cost is a typical scenario for you, then you will need to stand your ground on the deliverables, i.e., that your requirements were clearly and completed stated in the first place, that they are in fact delivering what you asked for, that your internal reviews and testing are rigorous and standardized, that the bugs you find get resolved and are not left in for the next release. This is basically an adverserial relationship and you will need to be above board and have good processes in place; otherwise how can you hold them accountable? The contract will need some teeth too for missed deadlines, for incomplete functionality. Saving Changes...
Robert PennSr. Project ManagerAlexandria, Va, United States
Given that you are working in a fixed cost environment, you cannot rely on your client's estimates (not that you should anyway). You are assuming the risk and if your estimate is different from the client's, you need to be prepared to justify it and stand your ground. Obviously, you need to do this in a cooperative manner, but you need to be able to specifically identify factors the client may have overlooked and you need to be very clear about any assumptions you made in creating your plan. You also need to thoroughly assess the risks and have contingency plans ready. Saving Changes...
We have done our estimates thoroughly.. still there is always a possibility of that some small thing is missing though that scenario has not happned yet. and if so hopefully the risk plan or buffer will take care of this.
But pricing for the project is done by Marketing people(i.e rate per hour to charge) and not by P.M.
Problem is in maintaining expected gross margin when revenue is fixed and expenses (like salaries) are not.
Saving Changes...
Selva Saravana PuvananthiranDelivery Lead Senior Manager| Accenture Solutions Private LimitedChennai, Tamil Nadu, India
One other thing that I would recommend is "Brainstorming sessions", especially during the early stages of a project. These would give you different perspectives/approaches to achieving the project's goal. You might ask "Where are the resources?, I haven't got any resource assigned". Sometimes it is one of those Catch 22 situations. But in most cases, you would have some idea as to who would be part of this project. Otherwise, you may have to get help from your neighbouring teams for that purpose. Saving Changes...
"Thousands of candles can be lighted from a single candle, and the life of the candle will not be shortened. Happiness never decreases by being shared."
