Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
Lately I've been feeling like I'm being pulled in different directions. In my company there are a lot of forces demanding my time and I'm having a hard time deciding which direction to focus my energies.
I have the choice of several different coding projects, some of which could demand a lot more work over time, and present unknown challenges.
How do you decide what to work on next in the big picture? Grease the squeakier wheels? Low hanging fruit? (translation: easier projects)
Do you have a system for determining and reaching your goals?
We've used a value graph to identify projects based on value vs. effort, as a part of lean.
A few of the things I ask that affect what I work on :
Are any of my tasks holding up other developers or keeping other people from being able to do their work? If so, it'll probably get done first.
Do I have any tasks with deadlines coming up? If so, it might be the next candidate to work on, unless I can justify something else being worth the task slipping schedule.
Will work on any of the tasks affect (make obsolete / make easier / make more difficult) any of the other tasks I have? If so, it might get moved up.
Is there a good chance that any of the tasks will change (requirements still not concrete / other tasks out there that might affect it), making time spent on it now likely wasted? If so, it gets moved down.
Are there any things that just really bug me, that I think I can get done before anyone notices that I'm not working on whatever my boss thinks is the highest priority. (which is justified because it'll distract me from thinking about the other things).
Are there any tasks I should work on while things are still fresh in my mind?
... other than that, we go with a combination of whatever sort of fixed deadlines I have, what tasks I have that might be holding up other people, what the boss wants first (I like this boss, and I only have one giving me tasks ... in the past, I'd've answered differently), which ones seem more interesting, which ones I can get done quickly to just get them off the list, etc.
There have been times when I've had more than one manager, and I just had to put everything on a list on a whiteboard, and told them to number them (17 items, which kept growing). Management balked, but I was sick of getting bitched out at meetings week after week with stuff not being done, and having to go through the list of every 'emergency' task I was given. (and being told that any manager in the department was allowed to task me in the case of an emergency ... which was something like 30 people ... and being bitched at when I asked who got to decide if it was an emergency or not.)
When I have the choice: whatever seems to be the biggest challenge with the most fun attached.
Fun + challenge = rapid learning, to me.
And sometimes that takes me away from the technical stuff - people can be a fun challenge too.
I tend to weigh 4 items based on things when deciding what to work on next:
Is this item a requirement for something else?
Can I work on this item yet (ie, am I waiting on something for it)?
How fast/easily can I get this item done?
How interesting do I find the work required for this item?
I my current team (working on a variety of Business Intelligence software projects), we've recently started adopting a variant of classical "agile" project planning and estimating -- everybody seems to be pretty happy with it so far, including us (developers of different levels of experience), the product managers (highly technical people, typically also with some development experience, but mostly interested in the business side of things), management (pretty technical at the level we report to, but also less-technical, more-businessy directors and VPs), and other stakeholders (users and would-be users of our software). But, of course, it is early times, and we'll adjust as we go along. (In the past few years I used other variants of this in very different application areas, such as cluster management software; but I've often also used more ad-hoc, less-structured approaches).
The outline is as follows. At each iteration (we're currently on 2-week iteration cycles), the PMs choose some "elementary units of business value" that they might like to get from projects in our area -- a typical unit would be one feature, a bug fix, some optimization aspect, etc. In a small meeting with tech leads and one or two senior engineers, each unit is decomposed into engineering tasks (and dependencies among tasks are identified). In a larger whole-team meeting, the relative "cost" of each task (how much time, roughly, it will take to perform that task relative to other tasks) is collectively assessed (we're using completely abstract units of effort we call "points", though I've seen other teams use less abstract units such as "ideal engineering-days"). The costs assessed include unit testing and technical documentation.
The tasks, each with its assessed cost, go on what's called "the backlog" for the team, together with "internal restructuring" tasks (typically refactorings that will deliver no new user-observable plus, but will make further development and maintenance more productive), also with assessed costs and a summary of expected benefits (which must be expressed in ways understandable to the PMs -- fortunately, as I said, ours are highly technical people). A refactoring may also, by engineering team consensus, be deemed a prerequisite of certain business-requested tasks (e.g. "makes no sense to work further on component X until class Y, too large, is properly split, which will take N points").
The PMs now get to order the tasks in the backlog in any way they prefer, based on the business value that completing the units those tasks make up would deliver, subject to the dependency constraints. They have a good idea of roughly how many "points" the team may accomplish in a 2-week iteration (our "velocity") based on past results, so they try to make sure some business-valuable release can be performed at the end of the iteration (as opposed to having many business-valuable thingies "in flight"... but none completed and deliverable to stakeholders yet!-).
The team then devotes about 80% of its time and effort to tackling the top-priority tasks as designed by the PMs (including pair programming some of the time, for particularly urgent tasks or for situations where one team member needs to learn more about some technology or some part of the codebase, and another team member who's an expert in those is available for pairing up with them for a while). The priority order is an important indication, but it's not entirey rigid (e.g. if the top task requires extensive work in Java, and the second one requires it in Python, I may well pick the second one, as my relative productivity will be enormously higher that way -- and vice versa for a team member who's a Java guru, etc etc).
"Priority 0" aka "Code Red" issues may arise at any time, and, if they do, by definition they will take priority over any other task (and be accounted for only retroactively in the planning, to make sure velocity is assessed properly). But, as we do a pretty good job with testing, release engineering, and other quality-assurance practices, those emergencies are fortunately few and far between.
This, plus other "mandatory" ways for engineers to spend their time (training courses, all-hands meetings, quarterly performance self-evaluations and peer reviews, etc), is supposed to account for about 80% of engineers' time -- the remaining 20% being time each engineer should devote to "something completely different" ("blue-sky" exploratory projects, "egineering community" efforts, open-source contributions, etc, etc), not directly related to the projects at hand. Nobody actually measures the hours precisely, but that's still a useful guideline (I keep thinking of ways to make measurement easy and painless that I could implement in my 20% time, to help me allocate time and effort more precisely, but I haven't actually gotten any round tuits yet;-).
Easy. I ask my boss.
High value + Low risk.
Only go on high value + something with higher risk if you already have a track record in the company / credibility.
Easy: What is the highest and best use of my time.
If I am involved in a project and that isn't the answer to that question, I ask myself why I'm working on it and how soon can I finish it.
:) On Job i left this decision n my Project Leader and Team Leader, As they know better
"What is project priority"
At home, i do where i see fun, learning and challenge
When I have a choice about which job to start next I try to find a balance between two things: quick, easy fixes that are highly visible (e.g. fix the non-critical bug that a user has been complaining about) and taking on a project where I can use something I've been learning about. I find if I alternate between those types of jobs I can keep myself and my co-workers happy.
I'd look at what has the highest priority from management's perspective for an intial prioritizing of upcoming projects. If they are all priority 1 projects, then there are a few other factors that may help my decision:
Do I see how valuable the project will be to the organization? Is this the type of thing that really helps with the competitive advantage that we have?
Does there seem to be a buildup of projects of a specific size? For example, are lots of little projects being ignored for the few really big ones? If so, I may take some of the little ones that may be seen as quick wins that may help my team look good.
Do any of these projects use my strengths? This can be a bit hard to determine but it could help a lot with motivation, at least using the Marcus Buckingham interpretation of a strength.
What teams and structures are in place for the other projects? I don't think I'd want to join a project that looks like a massive train wreck about to happen. Is there enough structure so that I won't go off and do my own thing that may hurt the project's chances of success? Do I believe I could handle working with X using methodology Y and technology Z?
Those are a few of how I'd look at making the decision, along with talking to my manager as part of this is his job, right?
You should ask yourself a question. Are you pursuing a general IT career path which may or may not include your current company, or, do you intend to have a long career with your current employer?
If you intend to have a succesful IT career moving around differnet employers then, sadly, the most succesful strategy is "buzzword collecting". Identify the current/next big thing and try to get it on your CV. e.g. FInd a trivial AJAX with SOA back end project which may never go to production, this will enhance your value to future employers even if the project had little value to your current temployer.
If you plan on a long career with your current employer, the most succesful strategey would be to align your goals with the business. For instance the most critical project for the business may be upgrading an old unsexy VB/Oracle stock control package to include an ancient EDIFACT interface with a new supplier. If you are seen as a key player in the success of such a project you will rank very highly (and rightly so) in your employers esteem, and your opinions and advice will be taken seriously.
Since you didn't specify whether you talk from developer or manager perspective, I'll try to cover both.
Providing a framework for prioritisation of efforts is a management’s direct job. The immediate day-to-day prioritisation may stay with management or be handed over to developers.
The decision who should work on what and when in average company is likely to be perceived as a matter of power, control and prestige by both groups and one who makes the most prioritisation decisions as clearly more important player.
In shrewd companies, however, it is well understood that decisions have several interesting properties:
Each takes time and effort to make, which is diverted from doing the actual work.
Every decision is a trade off
To make a good trade off one who makes the decision needs all the right information in her or his disposal
Subsequently, management doesn’t have all the information to make every decision and nor they likely to have right information to make a good trade off in each case, but developers cannot spend their time doing hundreds of prioritisation decisions per day instead of producing software, nor do all necessary co-ordination.
Hence the solution is for management to create a simple framework for task assessment and prioritisation and hand it to developers who will quickly apply it on case by case basis, filling the gaps. In management lingo such framework is called strategy; it saves time by removing repetitive redundant decision making, gives focus and consistency to the efforts, and provides direction. It should be detailed enough to remove the burden of re-assessing the situation each time, but loose enough to allow developers to make right choices when it matters.
The framework itself may give very straightforward rules for making decisions or, alternatively, provide some analytical methods such as Pareto, SWOT, Cost Benefit, Expected Return analysis or Porter Five Forces etc. However, it is worth keeping the rules simple, unambiguous and as straightforward as possible.
Joel Spolsky made available to the world several very good internal software strategy documents written in plain English. Not all documents are directly to do with developing software (showing that it viable actually to have a different unrelated decision frameworks for various aspects of the company life). Also since the documents are several years apart it’s actually possible to see how these frameworks kept changing to suit the situation:
Fog Creek Compensation
Our .NET Strategy
Set Your Priorities
Fruity treats, customization, and supersonics: FogBugz 7 is here
If you're intrested in choosing what things to work on from a personal point of view one of the best advices around in my opinion is the one given by Paul Graham in his essay "What You'll Wish You'd Known".
Fundamentally as software developers we are business enablers. Your priorities should be in tandem with business priorities and be pragmatic between quick wins and larger strategic initiatives. Effort and Priority make an excellent matrix in which to score projects taking the least effort/highest priority first.
From the tone of your question it sounds like business priorities are either unclear or there is conflicting direction between stakeholders. This is the place to start and it will make your decisions much easier once it is resolved.
You really need to discuss this with the business because only they can tell you what has the highest value to them. After that, I would go after the items that carry the most risk because if something is going to cause a schedule to slip it's best to know early rather than late.
If you're having trouble with what the business priorities - usually caused by being on multiple projects with different stakeholders who all think that their project is the most important - you can try getting both stakeholders in a room to discuss which project is higher priority. Or you could delegate that negotiation to your manager as that is actually his job.
I tend to work on multiple projects at one time, so I will work on a harder project, make some headway, and when I get stuck and need to think about how to do the next part, I will go to some low-hanging fruit, so that I can continue to make headway, as I give my subconscious time to work on the harder problem.
But, it really depends on your priorities. I have never been good at just trying to impress people, so I just quietly go about trying to get work done.
If we're talking in a work environment, i go through and just prioritise things - what is mission critical, what is urgent, and then anything else just gets put into the list and it gets done in the order it comes in.
As for picking the next big project at work, i like to do what offers the greatest challenge. I had been working as a developer for a year and i had the opportunity to do some work for a very large company working with some security experts and doing things i'd never done. So i chose that, and it looks great on my resume.
In terms of personal development work (not as in self help), again i'll offer something that challenges me. It's got to be something that i haven't done before. It doesn't matter if someone else has done it - i haven't, and i can learn from that.
In the end, it all comes down to what value it holds for you, and what value it holds for the client. Luckily, i've got a few years of sales experience under my belt as well, so i can easily sell the products i need to to clients.
If your problem is one of procrastination, then perhaps you need to focus on getting rid of those jobs that you fear tackling most - or at least making some forward progress on them to reduce the stress of considering how far behind you are.
This book, by Mark Forster, provides some good tips.
Failing that, you might want to produce an iteration plan. Let everyone vote for jobs - whatever gets the most gets scheduled right away. that way every stakeholder, including yourself gets some input into scheduling.
I would ask the boss, if they wont make the decision then I would go for the project which I felt was going to be best for the company, in profit and moral of the team.
If I was torn between too projects i would go for the one that sounds like I can develop my skills more and be interested in most.
If a project sounds exciting I become more driven and determined too :)
Given the nature of your question, I'm assuming this is all work that somebody thinks you should be doing, but there clearly isn't enough time to do it all. Therefore, you are just looking for priority knowing full well that some items are likely not to get done.
Impact/Risk if the item isn't done.
Visibility - Does anybody else really care about this task
Alignment with department goals - weed out things that really aren't your job
Alignment with company goals - weed out things that aren't important to your company's business.
Enjoyment factor
Alignment with career goals - Many people would rank this item significantly higher. Depends how important your career is versus what you do today. I've rank today's enjoyment a bit higher than long term career goals. Some projects may be horrible, but they can move along your career.
I guess it depends on how much is on the list. If there's a lot of low hanging fruit that's been on the list for a while, it may be worth while to take some time and clean some of it off. That way, there would be less demands on the available time and potentially more time or incentive available to work on the big projects.
Plus it can be cathartic to be able to cross a bunch of stuff off the list.
I will usually start working on a larger project first. Then when I feel I need to step away from it for a bit, usually so I can approach it with a clear mind later, I try to kick out some of the quick one-off tasks or simple projects.
I know that isn't very descriptive, but calling the occasional audible for distraction seems to work out well for me when tackling a big project list.
I tend to look at project from a learner prospective. I tend to choose a project that will help me learn something new, I also look for "cool" and intersting as well.
On tthe other hand you can choose your next project according to where it would lead you. Ask yourself if you have a career goal that project X will help you achieve. Perhaps a high profile project is better then intersting - at least for a short while.
One way to defide is to define several key pints that matter to you (i.e. new technology, intersting etc.) and try to rate each opportunity and see which gets the higher score.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
I new to Scrum and while I understand the team concept behind the Sprints, I imagine there still needs to be a guardian for the team who minimizes the interference from Product Owners who are not conversant in software development. What are your successes, and what horror stories have you lived through?
Update:
I am looking for the balance between coding to implement business process vs creating the appropriate architecture for a client. If the product owner is from the business unit there has to be guidance as to what amount of time should be spent on data model, etc.
Definition:
By "out of control" product owner I mean typically some one from the business unit who aggressively sets time frames while having no real technical ability to create that estimate. Typically this person will say: "I need those screens before the next meeting with the Operating Committee next week, so prioritize those work products first. We'll tackle the database after we talk to Operations."
Great answers everyone. Thanks for the good input.
The responsibilities are very clearly defined in Scrum - the Product Owner defines backlog items and prioritizes them, the developers commit on how much they can do in a Sprint.
So, a Product Owner simply has no authority at all to set estimates. Of course he can still say that he needs something to a specific point in time - that simply happens. But it's still the developers who will say whether it can be done. And if it can't, they have to work out together on how to change the scope or whatever else can be done to get the needs of the PO fulfilled as best as possible.
Now, how exactly the SM should act in a situation where this doesn't work smoothly depends a lot on the specific situation. I'd rather see him facilitate a good relationship and communication culture between the PO and the team than have him shield the team from the PO, though.
"there has to be guidance as to what amount of time should be spent on data model, etc."
Right. That's what prioritization is all about. You define the work, you prioritize. You work according to the priorities.
What can get out of control?
Redefining the work before anything gets done?
Redefining the priorities before the work gets done?
The solution is the same. Break the work into smaller pieces so something gets done before there's an opportunity to make a change.
If you have short (2-week) sprints, it's not possible to be out of control. If you go for slightly more practical 4-week sprints, then you have a small chance of getting into trouble.
The product owner is supposed to be the one that shields you from ambiguous or varying customer requirements.
The product owner must not give the estimates.
I don't think it's a question of "out of control".
"I need those screens before the next
meeting with the Operating Committee
next week, so prioritize those work
products first. We'll tackle the
database after we talk to Operations."
There is nothing inherently wrong with that statement by itself. If your app is properly abstracted, then your DB is separate anyway. The main problem with UI first is more psychological: The non-devs will assume that most of the work is done if they see screens and go bonkers when things "slow down". However, here's what I think your real problem could be:
The person you have flagged as a Product Owner is not owning the product, and so isn't taking on enough responsibility.
The product is the whole thing, not just the "functional requirements" (to borrow terminology). Your SM needs to have a sit down and be adamant that the PO needs to not try to push off understanding the scope of the behind the scenes work that needs to be accomplished. Once you're PO starts to look at the entire scope, then they can actually be your representative to the broader stakeholder community.
Ultimately, your SM is the one in charge of enforcing process. They should act like it.
I've used Agile at two different shops, both times it works well. I don't see how an out of control anything can ruin the system. Before the sprint, you plan all the tasks you will do and guesstimate how long they will take (always round up). Then you can figure out approximately how much work can be done during your sprint.
Most shops use 4 week sprints, and 6.5hrs of workable time a day. When a sprint has been set, you don't introduce new tasks and only unplanned work that creeps into a sprint is fixing bugs in the features you are adding, of course that is suppose to be included in your guesstimate time.
If you want a more specific answer, you need to define what you mean by an "out of control" product owner.
I have two things to say.
You probably have some kind of R&D manager (that is not necessarily scrum master) and that is not a product owner).
This guy can and should (I think) "protect" developers.
We were in situation when we had such a guy, and it worked pretty well. He helped us with getting non-functional stuff in the backlog for instance.
Now we don't have this guy. Our manager is scrum master. And he does pretty good job protecting us as well.
Though...the problem here is that generic scrum master has no official power, so he cannot say "you are not going to press them this much", but he of course can and should talk if he sees that teem needs help.
The team itself and product owner also evolve with time so that they start to care more of each other. Product owner understands when the team just does not commit to more or says "we need some time for non-functional stuff now".
But then - again - it's nice of course if there's a separate R&D manager whose main responsibility is taking care of developers...then it will be more balanced I think..
We also have support department which borrows developers for support tasks. Sometimes it is difficult to agree what is going or is not going to be done for this or that customer (because support wants it all).
For this case R&D manager - a very good idea too..
Ideally, I like the idea going completely lean so that developers don't need a manager or shield...but I don't know whether and how it works...:)
I agree with S. Lott. Short sprints are better. Short user stories can help to. We try to limit our user stories to 2 - 4 days max.
Make sure that all your user
stories are well defined and that
the owner in agreement with them.
Once a sprint has started, insist
that new tasks cannot be added to
the current sprint, but they can be
high priority in the next sprint.
Shorter sprints make this much
easier.
Also, in order to remove the
imposition of artificial deadlines,
you really shouldn't deliver items
from the current sprint until the
beginning of the next sprint when
possible.
The hardest part about agile development is discipline. Once you have a disciplined team and scrum master, the users get used to it and things move much smoother. I'm not sure if you use any software for project management, but take a look at Rally. They have made some major improvements over the past year or so.
The iteration (Sprint in Scrum) scope should not be changed during the iteration. That's why only one iteration is planned at a time. As S. Lott pointed out, the shorter the iteration, the sooner the Product Owner will be able to get new things planned.
The Scrum Master role is to isolate the Team from such pressure and shall say to the Product Owner that new requests have to wait for the next iteration.
Now the Product Owner role is to maximize the value of the work the Team produces, so if there is a new top-priority item, which could not wait for the end of the current iteration, it is still possible to replace items with similar estimate and that have not been started.
This should be the exception, not the rule.
Stick with the clearly defined rules of engagement then you(SM) can rather spend the time leading your team.
An agile team is Consist of Developer, Business analyst ,Tester ,DBA ,Scrum master and Product owner.All are working as one feature based team.
Agile methodology is here to help business to accelerate the faster product development. The product owner can define the priority and change the priority of it. Actually, it is a Scrum team ,who estimate it including (SME, Developer ,designer ,tester…. Everyone).Each team member brings a different perspective on the product and the work required to deliver a user story and one sprint comprises with big and small user story. If Scrum team feels that it can't be done within sprint then it needs to be a divide into the small chunk of the user story and estimate based on the stack trace involved to developed it.
i.e. If Product Owner(PO) want the specific user story need to finish first but if that story included the multiple changes (i.e. Frontend and backend including database) and it can't complete in one sprint , Scrum team can follow below key rules:
Key Elements :
Divide into the sub-user story based on stack track
Estimate each user story related to this
Scrum master should Informed the Product Owner about the timeline
to finish this user story based on team current team velocity
Product owner should be mature enough to understand the timeline as it
can't be completed within the sprint.
If Still PO has the problem for priority ,He/she can consult the
Scrum Master/Coach.
At a glance, Agile is more for helping business but need to take care that
it won't overload scrum team . As it is a regular process for
iterative development.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I currently work for a bespoke software agency. Does anyone have any experience of how to win well priced work?
It seems there is so much competition from offshore/bedroom programming teams, that cost is extremely competetive these days. I feel that it is very different compared to a software product company or an internal IT department in terms of budget.
As someone else said before, we only ever really get to version 1.0 of a lot of our software, unless the client is big enough. In this case it doesn't make business sense to spend ages making the software the best we can. It's like we are doing the same quality of work as internal IT staff. Also a lot of our clients are not technically minded and so therefore will not pay for things they don't understand.
As our company does not have the money to turn down work it often goes that we take on complicated work for far too little money. I have gotten a lot better at managing change and keeping tight specs, etc. It is still hard.
Edit-----------------------
Almost 3 years on from this post and I can list some important lessons that I have learnt since then.
Please see below for my answer
If you are concerned with doing too much work for too little money then work on an hourly basis. Yes, that is harder to sell in most situations.
Maybe you can try a two-phased approach instead. Have a very short initial engagement where the deliverables are very specific requirements documents that become the property of the client. You risk having to compete for the actual development but you take away the risk of pricing the project too low because you will already understand what the client is like to work with, as well as, the application requirements.
Once you win the work at a fair price then use the best practices suggested by mathieu to help ensure quality and productivity which both lower the cost you incur.
What you described in your post, (not your question), I think is a sales, management and marketing question first and foremost.
You say that your clients are not technically minded, this will require to have a cohesive sales, consulting and communications strategy, this isn't about programming skills.
Also, if your company constantly accepts projects that are too complex or expensive for your team, and you deliver low quality products you'll sooner or later be stuck in a hole. You will attract customers that you do not want, and existing clients will be turned off by your 'incompetence' and sooner or later find another company on which they'll try to play the same price game. Those clients are worth nothing in my opinion.
You ask 'how do you win well priced work'? People are social animals, they talk with each other. If there's a market perception that you are an unreliable company, people and future clients will sooner or later know. Customers don't care whether you offered them a product at a really low price, on a too tight schedule - It's not really their error, it's you who accepted it. So once again, I think whole ordeal is a bad business practice.
I found that you really have to define tight specs on jobs with low budgets, define what you will and can deliver, tell them the price, stop your boss from offering too many long term customer discount price tags because they are too afraid to lose the client. Communicate early and often when things start to get out of hand. Write precise offers for additional features. Write these precisely down, don't rely on phone conversations (you: "that's an additional 4 hours of work", client: "ok"... 4 months later, client "what was that again??? why am i supposed to pay for this").
Now of course, one way you keep prices down is by not hiring complete morons that might be initially cheaper than better qualified programmers. This is a shortsighted approach and will fail miserably.
It is the relationship with your customer that will win you additional business. One developer actually stepped forward and halted a project because his sales consultant basically lied to us concerning a solution set. The developer then offered a straight forward, bare bones solution within the same budget and he delivered on time.
This guy and his team has been consulting at my company now for over 6 years. His integrity and earnest, hard working nature has been an immense advantage, and he has found quality people to work for him as his reputation has grown. His honesty is worth more than any savings I could get by shipping my company's intellectual assets overseas.
"so much competition from offshore/bedroom program teams" - sounds like you guys need to put some time into networking. At the end of the day, people like to do business with people, not with businesses. If you're well known and liked in your client communities, you'll be the front-runners and you'll get a better price from the confidence you have built. And referrals will give you a powerful edge - ask for them.
"our company does not have the money to turn down work" - lot's of companies have this as a start point, but ultimately you have to get past this approach The time you spend on these types of jobs stands in the way of being successful. You need to make decisions about what type of work you want to do (and who the customers will be) and just as importantly what you don't do.
As a consultant, I have personally moved to an hourly-rate-only model for just this reason. I have been burned by too many contracts-gone-wild, and I feel your pain.
In the end, people who only ever go with the lowest priced proposal will be trouble for your company. While you can't be so choosy, such that you don't ever get projects, you definitely want to steer clear of contracts whose supporting management are so agnostic about the actual software development process that they only look at the initial price tag for something. Usually, it's the stuff not in the contract or specification that changes the profit margins and timelines.
It's often in you best interest to be picky up front rather than lowering prices in order to receive a wave of what end up to be trouble-clients anyway. In your case, while there's always the contention between an RFP that is not as concise as a technical requirements specification, initial quotes should be understood as a general estimate based on the level of clarity in the RFP.
And I definitely agree kitsune, that if your company is consistently accepting contracts that don't fit your company's development expertise or bandwidth, all that will result is overhead and bad reputation.
This could be seen as quick guide to the above problem.
Proposal Document
Start with a proposal document that explains your understanding of the clients needs as best as possible. This can be done in 1-2 pages of writing as a minimum. It can start heading towards requirements, but it should be more casual than that.
Budget Document
Now go to Excel and list all the tasks in the project you think you will have to do. Put down the times in days, none bigger than 2 (0.25, 0.5, etc.).
Add a column for testing, and make it a percentage of the development time (20-30% is normal)
Now add a column for management (project + account) and add a % of time for that (over the previous two columns). 20-40% is normal. (70-30 split pm/am)
Set a day rate for your company. You can get more complex and have different rates for different user functions, but as a minimum set a rate that will mean that you will have a good margin whatever the work is being performed.
Work out what the value is for the total days that has been recorded so far. Then add a contingency amount on top of this (for fixed price work) 10-20% is normal here, but can change based on experience with the client and the amount of change you are used to with them.
At this point you can discount the total amount, which is better than lowering any other part of this document, as it will show the client that you are not magically making jobs go faster, rather you are removing some of your margin. They should therefore not expect you to reduce the timeframe of the project.
**Important - Analyze your client's budget and business when developing a costing. There is no point in you delivering a costing designed for a huge enterprise to your mate who wants an application done cost effectively. Likewise, make sure that you charge correctly to an organisation that will be used to high end freelancer rates.
Think like a business analyst. Not only will it help you make the client happy when they see your costs, but it will probably give you a greater insight into their business. If they are going to make money by using you, then you are probably onto a winner. If you can't ask directly how much money they have to spend with you, work it out by asking how many customers they have, what they charge, how many employees they have, etc. You should then be able to work out if what you are proposing is going to be profitable for them.**
Go back to your proposal document, and add a table with sections for design, development, management, etc... You could show the client your costing sheet in certain circumstances, but it is better to avoid complexity in most cases. It's there as a backup though, and you didn't just cough up a number.
Timeline Document
Take the list of design and development tasks from the budget, and put it into a new sheet (or Project if you're posh like me). Put in the start and end dates of each section adding roughly 30-50% extra on top.
Add some graphical representation of the days as blocks in Excel or use a Gantt template like this one.
Go back to your proposal document and add key milestones from the timing document.
Proposal stage completed
Send or present your proposal to your prospective client. Hopefully they are excited with what you have proposed and happy to proceed to the next stage, full requirements gathering. In subsequent projects with the same client you may be able to go straight to requirements.
Requirements stage
List each requirement against a separate id, either 1,2,4,5 or 1.1,1.2,1.3. It doesn't really matter, but the second one can help with large lists.
There are some tests for requirements and you can try to follow these, but sometimes they don't apply (some requirements might be design led for example). Some of these are: Is the requirement testable, is it singular, is it clear? I'll try to find a link to this somewhere.
This is my developer standpoint:
Version control best practices: Keep the trunk clean, don't commit code that doesn't compile, and commit frequently
Continuous integration
Unit testing (with code coverage)
Automatic deployment on test servers
Automatic packaging of the application
Automate as much as you can :)
Also, hire good developers, and treat them well :)
Sell fixed price, fixed scope work, not hourly work. That mitigates your customer's risk of an over-run (you absorb all the risk, but you're doing that anyway), and frames the project in terms of the value of the software, not the quality of the effort going into it.
We are trying to build a product and reuse existing experience. Comparing to UK in Ukraine (where I work) salaries are lower, but still 4-5 times higher than in India.
So far, the best result is to get two new clients, which need a similar solution, so we can offer better pricing and we are more confident in our estimate.
BTW, I checked out whywaitdigital.com, and it seems that we have a product which your clients might need. We do portals - editorial, B2C, geo-enabled product catalogs and we use ASP.NET MVC also. You can find contact information on our website, www.socialtalents.com.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
We have a large backlog of things we should do in our software, in a lot of different categories, for example:
New problem areas for our products to solve
New functionality supporting existing problem areas
New functionality requested by our existing users
Usability and "look" enhancements
Architectural upgrades to the back-end
Bug fixes
Managing all of these in a sensible fashion is a job that falls to Product Management, but it is tricky for a lot of reasons. Firstly, we have a number of different systems that hold the different things (market requirements document in files, bugs in a bug database, customer requirements in our help desk system, enginering's wish-list on our intranet, etc). And secondly, many of the items are of wildly different size, scope, complexity and of course value, which means that choosing isn't as simple as just ordering a list by priority.
Because we now are fairly large, have a complex product and lots of customers, the basic solutions (a spreadsheet, a google doc, a basecamp to-do list) just isn't sufficient to deal with this. We need a way to group things together in various ways, prioritise them on an ongoing basis, make it clear what we're doing and what is coming - without it requiring all of someone's time to just manage some tool.
How do you manage this in a way that allows the business to always do what is most valuable to existing customers, helps get new ones, and keeps the software innards sane?
Note that this is different from the development-side, which I think we have down pretty well. We develop everything in an iterative, agile fashion, and once something has been chosen for design and implementation, we can do that. It's the part where we need to figure out what to do next that's hardest!
Have you found a method or a tool that works? If so, please share! (And if you would like to know the answer too, rate up the question so it stays visible :)
Addendum: Of course it's nice to fix all the bugs first, but in a real system that actually is installed on customers' machines, that is not always practical. For example, we may have a bug that only occurs very rarely and that it would take a huge amount of time and architectural upheaval to fix - we might leave that for a while. Or we might have a bug where someone thinks something is hard to use, and we think fixing it should wait for a bigger revamp of that area. So, there are lots of reasons why we don't just fix them all straight away, but keep them open so we don't forget. Besides, it is the prioritization of the non-bugs that is the hardest; just imagine we don't have any :)
Managing a large backlog in an aggressive manner is almost always wasteful. By the time you get to the middle of a prioritized pile things have more often than not changed. I'd recommend adopting something like what Corey Ladas calls a priority filter:
http://leansoftwareengineering.com/2008/08/19/priority-filter/
Essentially, you have a few buckets of increasing size and decreasing priority. You allow stakeholders to fill them, but force them to ignore the rest of the stories until there are openings in the buckets. Very simple but very effective.
Edit: Allan asked what to do if tasks are of different sizes. Basically, a big part of making this work is right-sizing your tasks. We only apply this prioritization to user stories. User stories are typically significantly smaller than "create a community site". I would consider the community site bit an epic or even a project. It would need to be broken down into significantly smaller bits in order to be prioritized.
That said, it can still be challenging to make stories similarly sized. Sometimes you just can't, so you communicate that during your planning decisions.
With regards to moving wibbles two pixels, many of these things that are easy can be done for "free". You just have to be careful to balance these and only do them if they're really close to free and they're actually somewhat important.
We treat bugs similarly. Bugs get one of three categories, Now, Soon or Eventually. We fix Now and Soon bugs as quickly as we can with the only difference being when we publish the fixes. Eventually bugs don't get fix unless devs get bored and have nothing to do or they somehow become higher priority.
The key is aggressive categorization and prioritization.
Fix the problems which are keeping customers away quickly and add more features to keep the customers coming. Push back issues which only affect a small number of people unless they are very easy to fix.
A simple technique is to use a prioritization matrix.
Examples:
http://erc.msh.org/quality/pstools/psprior2.cfm
http://it.toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381
Also useful is the prioritization quadrants (two dimensions: Importance, Urgency) that Covey proposes: http://www.dkeener.com/keenstuff/priority.html. Focus on the Important and Urgent, then the Important and Not urgent. The non-Important stuff...well.. if someone wants to do that in their off hours :-). A variant of the Covey quadrants that I've used is with the dimensions of Importance and Ease. Ease is a good way to prioritize the tasks within a Covey quadrant.
I think you have to get them all into one place so that the can be prioritised. Having to collate several different sources makes this virtually impossible. Once you have that then someone/a group have to rank each bug, requested feature and desired development.
Things you could prioritise by are:
Value added to the product
Importance to customers, both existing and potential
Scale of the task
You should fix all the bugs first and only then think about adding new functions to it.
All of this stuff could be tracked by a good bug tracking system that has the following features:
Ability to mark work items as bugs or enhancement requests
Category field for the region of responsibility that the work item falls under (UI, back-end, etc)
Version # field for when the fix or feature is scheduled to be done
Status field (in progress, completed, verified, etc)
Priority field
Since you already are doing things in agile fashion, you could borrow some ideas from XP:
put all your stories in big pile of index cards (or some such tool)
now developers should estimate how big or small those stories are (here developers have final word)
and let client (or their proxy -- like product manager) order those stories by their business value (here client has final word)
and if developers think that there is something technical which is more important (like fixing those pesky bugs), they have to communicate that to client (business person) and make client to rise that priority (client still has final word)
select as many stories for next iteration as your teams velocity allows
This way:
there is a single queue of task, ordered by business needs
clients get best return for their investment
business value drives development, not technology or geeks
developers get to say how hard things are to implement
if there is no ROI, task stays near bottom of that pile
For more information, see Planning Extreme Programming by Kent Bech and Martin Fowler. They say it much better than I can ever do.
I'm not sure if the tool is as critical as the process. I've seen teams be very successful using something as simple as index cards and white boards to manage fairly large projects. One thing that I would recommend in prioritization is make sure you have a comprehensive list of these items together. This way you can weigh the priority of fixing an issue vs. a new feature, etc..
Beyond any tool and process, there should be... some people ;)
In our shop, he is called a Release Manager and he determines the next functional perimeter to ship into production.
Then there is a Freeze Manager who actually knows about code and files and bugs (he is usually one of the programmers), and will enforce the choices of the release manager, and monitor the necessary merges in order to have something to test and then release.
Between them two, a prioritization can be established, both at high level (functional requests) and low-level (bugs and technical issues)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
We are just starting on a pretty big project with lots of sub projects. we don't currently use any kind of named process but I am hoping to get some kind of agile/scrumlike process in by the back door.
The area I will be focusing on most is having a good backlog for the whole project and, at least in my head, the idea of an iteration where some things are taken from the backlog, looked at in more detail and developed to a reasonable deadline.
I wonder what techniques people use to break projects down into things to go in the backlog, and once the backlog is created how it is maintained and ordered. also how relationships between elements are maintained (ie this must be done before it is possible to do that, or this was one story now it is five)
I am not sure what I expect the answer for this question to look like. I think what may be most helpful is if there is an open source project that keeps its backlog online in some way so I can see how others do it.
Something else that would get +1 from me is examples of real user stories from real projects (the "a user can log on" story does not help me picture things in my project.
Thanks.
I would counsel you to think carefully before adopting a tool, especially since it sounds like your process is likely to be fluid at first as you find your feet. My feeling is that a tool may be more likely to constrain you than enable you at this stage, and you will find it no substitute for a good card-wall in physical space. I would suggest you instead concentrate your efforts on the task at hand, and grab a tool when you feel like you really need one. By that stage you'll more likely have a clear idea of your requirements.
I have run several agile projects now and we have never needed a more complex tool than a spreadsheet, and that on a project with a budget of over a million pounds. Mostly we find that a whiteboard and index cards (one per user story) is more than sufficient.
When identifying your stories, make sure you always express them in terms that make sense to your users - some (perhaps only small) piece of surfaced functionality. Never allow yourself to slip into writing stories about technical details that you could not demonstrate to a user.
The skill when scheduling the stories is to try to prioritise the things you know least about first (plan for what you want to learn, rather than what you want to do) whilst also starting with the stories that will allow you to develop the core features of your application, using subsequent stories to wrap functionality (and technical complexity) around them.
If you're confident that you can leave some piece of the puzzle till later, don't sweat on getting into the details of that - just write a single story card that represents the big conversation you'll need to have later, and get on with the more important stuff. If you need to have a feel for the size of what's to come, look at a wideband delphi estimation technique called planning poker.
The Mike Cohn books, particularly Agile Estimating and Planning will help you a lot at this stage, and give you some useful techniques to work with.
Good luck!
Like DanielHonig we also use RallyDev (on a small scale) and it sounds like it could be a useful system for you to at least investigate.
Also, a great book on the user story method of development is User Stories Applied by Mike Cohn. I'd certainly recommend reading it if you haven't already. It should answer a lot of your questions.
I'm not sure if this is what you're looking for, but it may still be helpful. Max Pool from codesqueeze has a video explaining his "agile wall". It's cool to see his process, even if it may not necessarily relate to your question:
My Agile Wall (Plus A Few Tricks)
So here are a few tips:
We use RallyDev.
We created a view of packages that our requirements live in.
Large stories are labeled as epics and placed into the release backlog of the release they are intended for. Child stories are added to the epics. We have found it best to keep the stories very granular. Coarse grained stories make it difficult to realistically estimate and execute the story.
So in general:
Organize by the release
Keep
iterations between 2-4 weeks
Product owners and project
managers add stories to the release
backlog
The dev team estimates
the stories based on TShirt sizes,
points, etc...
In Spring planning
meeetings the dev team selects the
work for the iteration from the
release backlog.
This is what we've been doing for the past 4 months and have found it to work well. Very important to keep the size of the stories small and granular.
Remember the Invest and Smart acronyms for evaluating user stories, a good story should be:
I - Independent
N - Negotiable
V - Valuable
E - Estimable
S - Small
T - Testable
Smart:
S - Specific
M - Measurable
A - Achievable
R - Relevant
T - Time-boxed
I'd start off by saying Keep it Simple.. use a shared spreadsheet with tracking (and backup). If you see scaling or synchronization problems such that maintaining the backlog in a consistent state is getting more and more time-consuming, trade up. This will automatically validate and justify the expenditure/retraining costs.
I've read some good things about Mingle from Thoughtworks.
here is my response to a similar question that may give you some ideas
Help a BA! Managing User Stories ...
A lot of these responses have been with suggestions about tools to use. However, the reality is that your process will be the much more important than the tools you use to implement the process. Stay away from tools that attempt to cram a methodology down your throat. But also, be wary of simply implementing an old non-agile process using a new tool. Here are some strong facts to consider when determining tools for processes:
A bad process instrumented with a software tool will result in a bad
software tool implemention.
Processes will change based on the group you are managing. The
important thing is the people, not the process. Implement something
they can work successfully in, and your project will be successful.
All that said, here are a few guidelines to help you:
Start with a pure implementation of a documented process,
Make your iterations small,
After each iteration talk with your teams and ask what they they
would change, implement the changes that make sense.
For larger organizations, if you are using SCRUM, use a cascading stand-up mechanism. Scrum masters meet with thier teams. Then the Scrum Masters meet in stand-ups of 6 - 9, with a Super-Scrum-MAster responsible for reporting the items from the Scum-Master's scrum to the next level... and so forth..
You may find that have weekly super-scrum meetings will suffice at the highest level of your hierarchy.