Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I've just come from a discussion about who is best placed to give estimates on a given piece of work.
At a detailed level I'd always say that the best estimate comes from the person who actually has to do the work as they have the full understanding and this gives them complete buy-in to the , however at a higher level of abstraction (i.e. at overall project level) I'm not so sure.
I'm reminded of chapter 5 in Peopleware which gives the results of an Australian study from 1985 - best link I could find is here.
I'm particularly interested in your focus here - are you answering as a developer, architect, prject manager or whatever?
I'm answering this as both manager (present) and developer (past).
High level estimates should come from the team/project leader, but with input from the developers. They should also be given in the form of a range - most likely to worst case with an indication of the confidence level of each.
There's no way the team lead can know everything about the project in sufficient depth so they will need some input from the developers, but the danger with this is that you get bogged down in the details too early in the process. Equally, individual developers will not have a broad enough knowledge of the project (unless it's really small) to be able to give estimates on everything.
The manager then integrates these estimates and looks for conflicts and synergies to get the "big picture" - after all that's what we're paid for.
As a developer I wouldn't trust a manager who gave estimates without checking with the developers, but equally I wouldn't trust one who just asked the developers and passed that information on without "editing" it in some way.
The person responsible for signing off of an estimate should really be the project manager. That's their niche.
I'm not saying that PMs should make up the estimates however.
I'm saying that the PMs will need to take estimates from a variety of sources--technical, business, etc--for different parts of the project. In any project there'll be large parts that aren't technical.
Anything technical should be estimated by someone technical.
But, by the same token, anything non-technical should be estimated by an appropriate expert (CPA types call these SMEs--subject matter experts). An architect could estimate the technical solution. A BA the gap analysis. A manager could do the business process implementation. And so on.
But a PM is really needed to tie all those together into a high level estimate, particularly in terms of resourcing and working out the interdependencies and the critical path.
Developers generally should make the initial estimate. The Manager should be able to add a risk factor to it depending on who implements it. (for example : If the developer implementing it has a better knowledge than the one who gave the estimate, the risk would be lower).
The developer also may not have an idea on the other development areas of the project(assuming its huge). This is where a Manager's estimate comes into picture. IF the project is small then a developer estimate is good enough.
Everyone should give an estimate to the project manager: functional analysts, test analysts and the senior developers.
It's the PM's task to make sure they are somewhat realistic and to sum them up.
The tongue-in-cheek Agile answer is: nobody should, because it will be wildly wrong anyway.
I think it depends on the piece of work. A lot of times the project manager is more than capable to estimate how long it would cost to say, add some additional data on screen, change layout, you name it.
However, there are times when things are more complicated, especially if they deeply touch the architecture of the system. In that case, the project manager should consult the developer, architect, or both for their estimate, and exactly why it takes that particular time to implement.
Moreover, I think project managers should use a developer's estimate to get to the final estimate, like schar says. They should add a percentage of overhead, test time, risk factors, etcetera.
I'm answering this as both manager (present) and developer (past).
In our company developers are always involved in making estimations. We do high-level estimates on user-stories created by a business consultant.
The business consultant communicates the user-stories to me (technical teammanager) and a developer.
We schedule an estimation meeting to discuss the user-stories and the context of the project (three people, business consultant, developer, technical manager). Within the meeting both me and the developer make notes and write down needed hours per user-story.
After the meeting the developer fills out an estimation form and we make sure we both agree on that estimation. When finished the estimation form goes back to the business consultant.
Usually a high level estimation will be given in a range from x to x times 3 days.
For example: 40 to 120 days.
Obviously we only estimate development/test/deployment time which is needed. X percentage will be added for project management and technical management, risks and overhead.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
My question is how someone can really estimate the duration of a project in terms of hours?
This is my overall problem during my carreer.
Let's say you need a simple app with customer/orders forms and some inventory capacity along with user/role privileges.
If you'd go with Java/Spring etc you should have X time.
If you'd go with ASP.NET you should have Y time.
If you would go with PHP or something else you would get another time
right?
All say break the project in smaller parts. I agree. But then what how do you estimate that the user/role takes so much time?
The problem gigles up when you implement things that let's say are 'upgraded' ( Spring 2.5 vs Spring 3.0 has a lot of differences for example ).
Or perhaps you meet things that you can't possibly know as it is new and always you meet new things!Sometimes I found odd behaviours like some .net presentation libraries that gave me the jingles! and could cost me 2 nights of my life for something that was perhaps a type error in some XML file...
Basically what I see as a problem, is that there is no standardized schedule on that things? A time and cost pre-estimated evaluation? It is a service not a product. So it scales to the human ability.
But what are the average times for average things for average people?
We have lots and lots of cost estimation models that give us a schedule estimate, COCOMO 2 being a good example. although more or less as you said, a type error can cost you 2 nights. so whats the solution
in my view
Expert judgement is serving the industry best and will continue to do
so inspite of various cost estimation techniques springing up as the
judgement is more or less keeping in mind the overheads that you
might have faced doing such projects in past
some models give you direct mapping between programming language LOC
per function point but that is till a higher level and does not say
what if a new framework is intorduced (as you mentioned, switching
from spring 2.5 to 3.0)
as you said, something new keeps coming up always, so i think thats
where expert judgement again comes into play. experience can help you
determine what time you might end up working more.
so, in my view, it should be a mix of estimation technique with a expert judgement of overheads that might occur with the project. more or less, you will end up with a figure very near to your actual effort.
My rule of thumb is to always keep the estimation initially language agnostic. Meaning, do NOT create different estimations for different implementation languages. This does not make sense, as a client will express to you requirements, in a business sense.
This is the "what". The "how" is up to you, and the estimate given to a client should not give the choice to them. The "how" is solely your domain, as an analyst. This you will have to arrive upon, by analyzing the demands of the business, then find what experiences you have in the teams, your own time constraints, your infrastructure and so on. Then deliver an estimate in BOTH time, and the tech you assume you will use.
Programming languages and algorithms are just mediators to achieve business need. Therefore the client should not be deciding this, so you shall only give one estimate, where you as an analyst have made the descision on what to use, given the problem at hand and your resources.
I follow these three domains as a rule:
The "what" - Requirements, they should be small units of CLEAR scoping, they are supplied by the client
The "how" - Technical architecture, the actual languages and tech used, infrastructure, and team composition. Also the high level modeling of how the system should integrate and be composed (relationship of components), this is supplied by the analyst with help of his desired team
The "when" - This is your actual time component. This tells the client when to expect each part of the "what". When will requirement or feature x be delivered. This is deducted by the analyst, the team AND the client together based on the "how" and "what" together with the clients priorities. Usually i arrive at the sums based on what the team tells me (technical time), what i think (experience) and what the client wants (priority). The "when" is owned by all stakeholders (analyst/CM, team and client).
The forms to describe the above can vary, but i usually do high level use case-models that feed backlogs with technical detailing. These i then put a time estimate on, first with the team, then i revise with the client.
The same backlog can then be used to drive development sprints...
Planning / estimation is one of the most difficult parts in software engineering.
Then:
- Split the work in smaller parts
- Invite some team members (about 5-8),
- Discuss what is meant with each item
- Let them fill in a form how many hours each item is, don't discuss or let them look at others
- Then for each item, check the average and discuss if there is a lot of variance (risks?)
- Remove the lowest and highest value per item
- Take the average of the rest
This works best for work that is based on experience, for new projects with completely new things to do it is always more difficult to plan.
Hope this helps.
There is no short easy answer to your question. Best I can do is to refer you to a paper which discusses some of the different models and techniques used for cost analysis.
Software Cost Estimation - F J Heemstra
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In my organization we have to handle multiple projects with different technologies,like flex, iphone, .net, php etc. The problem is I know only java.
So if a developer says me that an issue will take 2 days to solve I really cant judge whether he is right or wrong.
How to handle this situation?
One more problem is that because I don't know a particular technology so its very tough for me to say that whether a particular thing is possible or not in that technology?
I prepare project plan, documents, contact with clients these things but have almost no controls on developers because my insufficient knowledge of all those technologies
What can I do about this?
If an estimate strikes you as a bit over the top, surely the developers should be able to explain what it is that will cause the delay. Especially if you know java - they should be able to explain it to a non-tech project manager as well (after all, the project manager might be required to explain to the customer).
Other than that; trust your developers. They probably don't underestimate badly enough to get you into a tight spot, but you should always give yourself some margin as well, when communicating with the customer. If they constantly over-estimate, you should notice that after a while.
This is from Scrum but it is applicable even if you don't do Scrum. In Scrum, only the developer is allowed to give an estimate of how long it would take to do something. Managers are not allowed to give, recommend or in any way modify that estimate. So first of all trust that estimate.
But.. most programmers are inherently over-confident. If a programmer says 2 days then it may take him 3 days to complete a task. The estimate does not reflect reality (at first).
The solution to this is to keep a record of the estimate. I usually write the task and estimate down on a piece of card and post it on a big whiteboard. If the task takes longer than the estimate then tactfully remind the developer and make a mental note. Next time, before making a new estimate drop subtle (or not so subtle) hints about missed deadlines or early completion. This way the developers will slowly learn to improve their estimates.
Be cordial in all this. The aim is to get accurate, reliable estimates - not to put pressure on people. The whole point of this is to train people to make better estimates. Trust me, having an accurate estimate is more important than missing a deadline. It is relatively easy to tell a client that a project will be delayed by 1 week if by the end of that week you can actually deliver the project. On the other hand repeatedly telling the client that the project will be completed "tomorrow" will quickly make the client lose trust in you.
A few other notes:
When I started this process it took around one month for most people to actually be able to give me accurate estimates. It's not that they were intentionally lying about previous estimates. It's just that people, especially programmers, don't actually know how to make good estimates without training.
Whenever developers come up with an estimate of more than 3 days I automatically ask them to break the task to smaller subtasks such that each subtask takes only 1 or 2 days to complete. This also automatically generates milestones that you can actually track to see if the task is going well or is stuck.
Explain this process to your boss and get his support. It is very hard (but not totally impossible) to do this if your boss keeps pressuring you because you will end up pressuring your developers. Your boss must understand that time estimates can only be made by people actually spending time doing the job.
you should probably trust your developer's estimates, yet expect that they won't always be 100% accurate, remember they are estimates. It might also be a good idea to use a process that has the acceptance built in that estimates are only estimates, and either doesn't require them (e.g. Kanban), or has features built in to adapt to the nature of estimates (e.g. Scrum).
PMs shouldn't really need to know that much about the technology, as that is what the developers are for, but I understand that is not always the case, particularly where the PM also has technical responsibilities.
So judging whether or not something is possible shouldn't be your responsibility alone, this type of evaluation should be delegated practically completely to the developers, at least regarding the technical considerations. You can still provide your evaluation where business, economic, and customer considerations reflect on the possibility or otherwise of some endeavor.
In short, leverage the developer's technical knowledge where it is needed.
Befriend your development team. Explain that your job is not to boss them around or tell them how to do something and how long it should take, but to help them co-ordinate and shield them from direct interaction with the clients.
Once you are in a situation of mutual trust, describe the needs of the client and rely on the estimates provided by your developers. They're the ones who have the knowledge anyway.
Should a client ask you for an estimate on the spot, answer that it's impossible to give an exact figure without putting some thought and expertise into it. If they insist, answer a large-ish figure (at least what it would take you to do that same thing in a language you know) and tell them that you will provide the actual numbers shortly.
Maybe your process could do with some help.. from your comments above i saw:
Step 1 -the PM has to communicate with client to build the project
plan...
Step 2- build the mock ups---
Step 3--get approval of those two documents from client and management
....
Step 4-- project starts
Where do the developers come in and estimate? If you're asking them at Step 4, it's too late as you've committed to some sort of schedule with your client and management.
To ensure everyone's expectations are correct, take along a trusted developer to Step 1. Before you present a plan just ask the dev; "how long could we build this with a team made up of n of our developers?"
This has a few advantages:
Better estimates
Sets more accurate expectations with both client and dev team
Increase commitment to those estimates from the dev team
1 and 2 should be obvious, but item 3 is important as people rarely like working to estimates set by someone else. While you may not be able to use the whole dev team in your estimating, use a trusted advisor.
I also do manage some small projects, some COBOL, some MS, mostly java.
I only really know java, and my skills need updating too.
We use a scope estimating tool, really just an excel sheet with fields the dev fills in to assess the impact. This helps the developers break down the problem into smaller pieces, it forces them to really think through the steps that need to get done and this gives us a more accurate estimate. Whatever helps the developer, helps you. :)
And then when we are done we compare the estimate vs actual and baseline it for future references. We define good estimates as having a variance of 10% or less.
Don't just blindly trust the developer's estimates - you don't know where he's basing that from, no one could ever know 100% of the technology/framework or data model or business rules or such. Know what he has factored in the estimates.
I believe trust is earned. If a developer has given bad estimates before, would you trust the estimates he'll be submitting next is adequate? I definitely won't, unless I see an improvement.
I've been a developer, and I have made quite a few bad estimates too. (Hhmm maybe that's why I'm less of a developer now and more of a manager.. )
The only way to get an accurate estimate is to break the task down into small units of work. The smaller and more focused the units of work, the more accurate the task estimate.
Getting the team together to discuss exactly what each task will involve is a great way to peer-review the proposed technical solution. Often a better technical solution is hatched by the team through detailed discussion of the task. This is a great use of time, and you'll easily recover the design-peer-review time once development starts.
If you sit in on these team discussions then you will start to understand the technology a bit better, and you will start to trust your programmers more as you understand the estimating challenges from their perspective. It is also a great way to cross-train the team, as you'll often hear the phrase "I didn't know you could do that" as developers share their knowledge. Make sure the team reviews are ego-free and friendly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Currently, my company utilizes agile as its development principal. I was approached by my boss to determine some methodology for determining the amount of work a project manger does on a given project in flight. To be honest, I can't really think of anything fool proof.
I guess the best question is how do we assess how busy, on a day to day basis, a project manager is?
Remember that ANY metrics you can come up with is most likely going to be gamed.
[ Do I get a badge for on-topic link to Joel On Software? :) ]
Having said that, you can try a union of the following approaches:
Developer feedback!!! (e.g. a good PM's feedback would be "I had problems X, Y and Z and he made them disappear"). Not so good for measuring how "busy" a PM is but really good for measuring how effective he/she is.
Volume and rated clarity of project plans (easily gamed)
Rate of change of project plans (easily gamed)
Amount of meetings/meeting time (easily gamed)
Success rates of projects (on timeliness vs. % of features delivered vs. customer satisfaction). Not easily gamed but devil's own work to normalize this across projects.
Timesheets will measure the amount of work in one sense (you can see how their day breaks down and so on) but not I think in the sense you want.
Ultimately I don't believe there is a useful metric for Project Managers in this sense, but I don't think that's an issue.
I think ultimately you should measure project success rather than "busy-ness". After all, why do you care how busy the PM is if they deliver successful projects?
One PM may spend half a day putting together a risk log and mitigation plan which contains 20 risks, another may spend 2 days putting together one which only has 5 risks but none of those numbers are any more useful as a metric than lines of code. The key thing is not how long you spent doing it, how many risks you identified, how big your mitigation plans are, but whether you actually managed risk on the project successfully.
You're better off looking at what a Project Manager is meant to do, which is to deliver projects on-time, to budget and to customer satisfaction (which I'd use as the ultimate measure of quality rather than defects).
After all, do you measure how "busy" the CEO is? Or is he just judged on the profit the company makes?
To do this:
Time - The only way it can really be gamed is by massively padding estimates and plans and this can be minimised by reviewing the plans and estimates and having all relevant parties agree them (developers, PM, client). The other side of this is that the PM must agree to the plan rather than have the implementation date foisted on him or her. You might want to measure this on either the overall implementation or each milestone.
Budget - Measurable but gameble. For most development projects the key thing her is honest timesheets from the developers and the best way to ensure this is to make it so the PM is the PM but not their line manager. That way the developers have someone to fight their corner (a technical director for instance) if they're being pressured to fill in timesheets to keep the budget down. Again the PM should agree the budget, it's not reasonable to expect him to deliver on something he's told you is unreasonable.
Customer satisfaction - Hard to measure so I'd suggest that you keep it simple and go with a straight forward post project review with the account manager and marks out of 10 for communication, delivery and whatever else is important. It is subjective but ultimately so is customer satisfaction.
But a lot of it depends on the company culture. For some organisations the key thing will be billable hours, others developer satisfaction will be part of the mix.
I am trying to understand WHY you have been asked to estimate the amount of work that a project manager does on a project.
At best it is just a request for a rule of thumb, otherwise it indicates that your boss just don't know the first thing about running a project. Even when projects looks very similar there will always be something unique about a project:
The team is not identical (teaching
the new guy the ropes takes time)
The spec might vary just a tiny bit
(and that tiny bit might double the
workload)
Even the season might influence the
outcome
and so on and so forth
Each and every condition on the project might change the workload of the project manager, so it will always be a subjective assessment.
I would suggest you use the same Burn Down and Level of Effort that you use for the developers. A PM's task in an Agile environment is a bit different (and from shop to shop it's different), but the PM should be able to provide a list of tasks, etc. I'm thinking positive and seeing it as your bosses approach to determining how much availability the PM has.
Most project managers equate responsibility with status, so a project manager who has spare capacity is quite likely to volunteer to take on a new responsibility, because it's in his/her own best interest. In all but the most functional organizations it's often better to be visibly overloaded, for that heroic look.
It's more likely to be in the organization's best interest to slightly under load its project managers, so that there is some spare capacity available should something start to go wrong. A project manager might well choose to apply his/her spare capacity in some constructive way in any case. Excessive politicking or other unconstructive activity is a good indicator of someone who could be more constructively deployed. Even on agile projects, workload tends to be uneven across a project cycle - e.g. delivery is often a management-intensive activity - somebody who is continuously heavily loaded probably has too much to do, and may be ignoring or hiding a serious problem.
If the next level of management conducts regular project reviews, pays attention to how many problems are being escalated, whether the project reports correlate with the news from the grapevine, and does some basic estimation on workload projections for each project manager, then the organization should be able to run a reasonably efficient system.
Managers tend to be political and psychological animals. Any methodology that doesn't take that into account is ignoring reality, so a good methodology for this problem is likely to be based more on observed behaviors than on hard numbers.
Excuse me if I am being to purist, but the tag and the question calls for Agile. What would be a project manager in Agile? You might either be trying to asses the work being done by a product owner or a scrum master?
In any case, both roles perform several tasks that are hard to measure, so probably your boss is looking at the wrong picture.
For instance, a scrum master is "The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent". Basically is a coach and a facilitator. Blocking disruptive requests or distractions created by higher levels of management by negotiation or persuasion to follow scrum practices is one of the skills commonly used by scrum masters. Several of these soft skills are hard to measure as "work" since they do not involve working on a computer or producing a report.
I think a the metric that your boss would benefit most from is more related on how effective the team is and how a scrum master is described to facilitate the work of his team-mates. DVK then has a very valid point, the metrics you create can be "gamed", so it is best to trust that your managers are busy if your projects are progressing and your teams are happy and work as a team.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm trying to determine some of the markers that indicate a project of limited resources.
In my experience a project becomes a ‘limited resources’ project because someone was desperate to sell a solution to a client. The results is a tight budget, features are culled and SDLC processes are cut to a minimum. These short-cuts are taken so the company has some chance of making a profit or even breaking even.
This is a list of things which I have seen go hand-in-hand with a project of limited resources:
Bare minimum amount of time allotted to QA
Strict bureaucratic process for off-spec work
Change request budget may be small or non-existent
Formalised processes get dropped in favour of using time for development
No time available for value-add QA like content checking (e.g. grammar or spelling errors in text).
Can’t do any content management or data entry for client
Have to go for ‘good enough’ coding solutions
No time allowance for hallway usability testing.
no budget for writing user documentation or manuals.
Generally no time for technology research before coding
No time to produce a risk analysis document
A production check-list may be used instead of a project schedule.
The is no time for a programmer to fill their ‘actual’ times vs. estimated times in the project schedule.
Progress updates given to clients may be less frequent or very basic
Less time is available to spend on understanding the clients business domain
Programmers may have to work unpaid overtime.
No time allotted for a project post-mortem
What other sure signs are there for a limited resources project?
===
EDIT
i will try clear up some of the confusion with an example. this is what i mean: the client is given a proposal/quote saying their project will cost $20k. the client then comes back and says "sorry, my budget is $16k maximum". the boss says "make the proposal $16k - we want this work".
so, effectively, you have to do a project with less budget then it should have. there are boundaries where it becomes ridiculous - if the client was to say "my budget is $4k" then you couldnt possibly do it.
and yes, sometimes a tight budget can become so silly that it was a bad business decision to accept the project in the first place (i.e. doomed project).
i understand that there is no such thing as a project with unlimited budget. often business people make the decision whether a project should be undertaken (a business person often isnt a project manager).
What you are talking about is not a 'limited resources' project, but instead a rushed and unplanned project.
A few items in your list I take issue with:
Strict bureaucratic process for off-spec work
Change request budget may be small or non-existent
Actually, these should be the norm for most projects. Who's requesting and paying for the changes, you or the client?
Can’t do any content management or data entry for client
No budget for writing user documentation or manuals.
If that's not part of the contract, why are you doing it?
Have to go for ‘good enough’ coding solutions
At some point, you have to stop at 'good enough', or else you are going to be polishing from now until the end of time.
Something I would add to your list are:
Office supplies become scarce or go under lock and key.
Corporate supplied food/beverages disappear
Down time disappears. 100% of your time on your time sheet must be dedicated to project work.
The printer/photocopier is running full-bore printing other staff member's resumes.
The Boss' door is shut for 90% of the day.
Quite frankly, I've never heard of a project that had unlimited resources. Even the government will put the brakes on something after a while.
So, from a pure logic perspective, all projects have limited resources.
Limited resources? All projects that I know of have limited resources:
time
developers
budget
Outdated or obviously beta documentation which doesn't jive with whatever release of the product on site, or documentation which looks like it's been down through several generations of Xerox copies.
No onsite installation or support. Depending on the size of the system being implemented, a company in good shape might send one or more of their developers to oversee the implementation, whereas a company that's tight might offer phone or email support only in a more "fire and forget" approach.
Continuous occurences of new,
forgotten features, assumed as
"obvious" and "implicit" by the user,
never stated in the requirements,
leading to discussion Bug vs. Change
Request.
Waterfall model adopted instead of an
iterative approach.
Customer protesting on the costs of
fixing, saying something like: "If
you have bugs, it is because you
didn't do your job right", not
accepting the tripple constraint
effects on quality when cutting
time/budget.
Pressure for lower prices for
maintenance and support activities
after project deployment in
production.
Pressure for adopting a fixed-price project (outsourcing) to transfer financial risk together with timeline risk.
"Under-priced projects"
If I understand correctly what you mean, you really are talking about projects where the resources available to the project are not appropriate to achieve the results that were promised to the client.
I can think of four ways for this situation to arise:
Wrong estimates when preparing the project plan
Requirements creep
Reducing the project budget without reducing the project scope
Inadequate resources (staff skills, computer resources, etc.) for the project scope
When people in the project become aware of the situation, they really have two options: cut costs or cut scope. Cutting the scope can be a hard sell and may endanger the project viability, so most of the time people opt for cutting custs, especially since cost can be cut in many ways without atracting the attention from the higher echelons:
Unpaid overtime
Reducing quality
Eliminating documentation
and so forth.
In fact, you may even look good as a project manager when you start cutting costs, since cost containment is one of the project manager's responsibilities! I assume that what you want is to find ways to diagnose an under-funded project. I think that instead of developing an extensive list of symptoms, I would strive to identify a general condition.
In my opinion, there is a general condition that allows to pinpoint an under-funded project. For most projects, staff is the biggest cost - or at least the second biggest cost that can be managed by the project manager. Whenever you find an experienced manager taking measures to reduce staff costs and those measures were not part of the original plan, then you can be sure you have an under-funded project.
Regards,
using the information you guys so kindly contributed i was able to pull it all together and write an article
ill put a link here in case someone in the future is looking for help on the topic:
Surviving An Under-resourced Project
--LM
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Based on what criteria they choose the projects and what are the things based on which they choose a project...?
Return on investment, if they want to stay in business.
Return on investment is ofcourse the final product. But it takes a number of factors to get there:
Their own expertise: Do we have people with skills needed to do this? Can we hire some?
Available resources: Programmers, Managers, Hardware, Time, Financial resources.
PR: Even if we dont get paid that much, will this project get us more business?
PR: Pay is great, but do we really want to be associated with this client?
Their Mission/Goals: What fields/niche do they want to compete in. Do they want to expand?
Past experiences: We did a project like this, it was horrible. Lets not do that again.
Past experiences: It was fun last time, AND we can reuse half the code! Lets do it!
Usually the management uses more sophisticated matrices and all to make their decision, but more or less, these are the factors they usually put in.
I am sure someone can provide a more specific/scientific answer.
Good question. The straightforward answer may seem to be Return on Investment (ROI). However, ROI is criticised for three reasons:
Short-termism: ROI is seldom calculated beyond 5-7 years (due to increasing discount rate on any cash flows produced in the future), some projects really worth doing realise full benefits much further in the future.
It’s hard or impossible to put monetary value on some things. The often cited example is human life. The other is moral principles. However, most frequently encountered thing in software world what is very hard to put a price on is opportunities that will never emerge unless this project goes live. It’s hard to put a value on the emerging opportunities, because we don’t know what they are until they actually emerge. And I don't mean opportunities that will simply not “open”, but specifically emerge.
ROI doesn’t take into account wider strategy. The importance of strategy in software world should not be underestimated and the strategy should take into the account specifics of providing software products or services. Geoffrey Moore’s “Crossing the Chasm” is a brilliant book I recommend and is very pertinent to the software world.
Joel’s recent instalment “Fruity treats, customization, and supersonics: FogBugz 7 is here” has a great sample of strategy document and the reasoning behind it. It seems that FogCreek plans to leave the bawling valley and enter the tornado (according to Geoffrey Moore’s classification) with their FogBugz 7.0 and hence the strategy of removing barriers that prevent people from switching to FogBugz, instead of spending time to introduce some more vertical features.
Other tools that can be used for selecting projects are SWOT analysis, Pareto analysis (i.e. choosing a project to address 20% of causes that are responsible for 80% of problems), PESTLE, Cost-Benefit analysis (similar to ROI, including the critique).
However, it seems that a sane strategy that states that the company is planning to do and not be doing in the finite period of time (often next year or two, in high tech market conditions are hard to predict beyond that horizon), gives a simple guidelines for choosing priorities and clear direction for joint efforts is the best starting point.
I also recommend reading a fabulous book “Almost Perfect” by Pete Peterson (former CEO of the maker of WordPerfect) that is available online. The book tells a real-life story of different strategies SSI Inc followed, some planned and stated and some ad hoc, and the way they were used to select what to work on.
ROI is only one measure. There are many other factors:
Risk management - for example, improving the process may not show any direct return on investment, but by adding e.g. unit tests the quality of the software can be improved and risk of a production bug reduced.
Compliance - there may be requirements by industry or government that need to be followed. Directly this may not show a return on investment because they may never be audited, but the downside to being non-compliant is huge (being shut down).
Manageability - providing metrics on bugs, project schedules etc. may not show a direct return on investment but it may allow them to better predict and manage their projects.
Security - this may be considered as a part of risk management, but it is a broad enough area to merit its own category. Making legacy code secure can cost a large amount of money and not show any immediate return, but there are obvious reasons why this is worthwhile.