How Can Marketing And Techies Best Work Together? 27
Chris Worth asks: "Something Slashdotters could help with here. We all know that asking a hacker for 'business' stuff like accurate deadlines and costings can be next to impossible. Trouble is, you can't run a business without this stuff... forcing us marketroids to guess it. So plans are laid, budgets are forecast, and schedules set without reference to the techies. Generally, this all ends in tears. What's a reasonable way to estimate the size and cost of a 'normal' (for example, a database-driven customer service app, with no fundamentally new technology needed) Web development project? Is there some equation - perhaps linking together number of program variables, length of spec document etc. - that'd lead to a decent guess as to how long a given number of people could reasonably be expected to deliver the project in? In other words, how can I be fair to my programmers?" It's nice to see someone in marketing trying to go that extra mile to make sure their programmers have enough time to do the job, but reality being what it is, this luxury happens infrequently enough. What would you techies want from marketing and what do you folks who work in marketing want from your IT staff? Is there a way to work things out that would make most camps happy?
Ach! (Score:3)
*Listen* to your programmers (Score:3)
I suppose this is going to sound anti-marketing, but my main problem (as a programmer working with marketing) wasn't an inability to provide scheduling, it was that my schedules were
After a while, it becomes rather pointless and tiresome you know are going to be useless next month.
Anyway, to provide some (perhaps) useful information: If you are not a programmer, you can't estimate a schedule. What you can do is guide the choices the programmers make when they do scheduling. List desired features with priorities. List desired finish dates (assuming staged rollouts). When the programmers say they can only do half of it in the allotted time, either accept it or work with them to adjust features/time/resources.
Once everybody agrees with the features and schedules, let them work. Don't take people away from the project for "emergencies". Don't add "just this tiny little feature". When you do both of the previous (and you will, because the real world is that way), be honest about what you're doing, and adjust the schedule.
At this point, you're probably thinking "Well, those darn programmers always ask for more time than they really need, so I need to force them to do more than they say they can." You're right. We do. That's because we've all been screwed over by feature creep and resource loss so many times that we know we have to overestimate to survive, because it's never the marketing guy who takes the blame for late products. Once your geeks learn they can trust you, their estimates will come closer to what they really think. Besides, nobody ever gets yelled at for beating a schedule, right?
Oops, that sentence was supposed to be... (Score:1)
After a while, it becomes rather pointless and tiresome to provide schedules you know are going to be useless next month.
Sorry about that...
Beware Scope Creep! (Score:2)
I've had it myself, and seen many friends deal with it: Scope Creep. In a nutshell (for those who haven't heard of it before), it's when the Customer initially wants A, and signs the contract for that. But then they want an extra feature here, another bit of flexibility there, and before you know it, you're on the hook for A++, not jus A anymore. This leads to broken deadlines, late nights, caffeine, gaming, and kernel mods, among other things.
What you have to do is lay out VERY SPECIFICALLY what the customer wants, and make sure your techies and the customer are talking the same language, or are at least on the same page. If there is any other feature to be added, the contract is modified, along with the timelines and whatever else needs to be. This effectively keeps EVERYONE in the loop, and forces the customer to realize that this "extra little feature" is actually a major technical undertaking and not just "adding a button on this part here".
From that, you should be able to fairly accurately get a first draft of a timeline up and going without having to pad it for extras. (There's the added benefit of KNOWING that the customer will want to add something, which means that if you've screwed up a timeline, you just have to wait, and it'll disappear underneath the new, improved timeline!) :)
Good luck!
Normal? (Score:3)
I think the only solution is to wait until the project is in the final stages before releasing any dates.
Re: (Score:1)
Different Strokes (Score:1)
One kind of geek will give you a deadline or receive a deadline and work like nothing else to match the deadline. This geek considers the deadline a competition, and he or she will do whatever it takes to make the deadline. While this may sound like an uber-programmer and hard worker, more times than not, bad code will be produced when this programmer feels the impending crunch.
Another type is the lazy programmer. He or she will code a little, read slashdot, code a little, read rootprompt, code a little, read arstechnica. When the deadline approaches and you ask the programmer what is up with the project, he or she will begin spouting excuses from every orifice about switching requirements, feature creep, unseen complications, etc. (Watch for the excuses involving heavy uses of acronyms like "the TCP/IP changover model for the hex-a-bit transceiver is not enabling the XML specification via the BSD socket..." -- they are trying to confuse you with meaningless geek mumbling.) These programmers need another programmer to get them going -- a oft-sought uber-programmer to get them to stretch their limits.
Another type cannot give deadlines because they see things as an engineer. The coder may realize what is to be implemented, but gets caught up in the micro-scale and just starts summing the hours together of work put into each method e.g. 3 hours + 2 hours + 4 hours +
There are many other types, but I feel as if continuing along this line involves just archetyping everyone I know.
It just comes down to communication and mutual understanding. A programmer likes to solve problems. In the zone, we want no distractions. We want to solve the problem and move to the next. We don't know how long it will take to solve the problem (or complete the system) because it does not matter. What matters is getting to the solution. And then, we are constantly interrupted with new problems brought about by others (Manager: "Wouldn't it be cool if our software ?")
Like I said, mutual understanding and communication... and to be left alone.
Jeremy
Re:my suggestion (Score:1)
--hiro
Accurate costing and schedules ARE possible. (Score:4)
There are two basic kinds of software operations, which may be departments within a larger effort, or stand-alone groups: engineered/designed programming efforts, or creative/customer service programming efforts. Both have their places in industry.
With the engineered group, software and changes are designed and planned (hopefully) before reaching the coding stage. Analysis and planning allows the programming time to become a factor of the amount of code versus the programmers' productivity, and typically there are numbers kept to track this. Estimates and schedules are usually well kept in this type of operation, however, the limiting resources are time and money. There has to be people time to design, plan, and track. This results in longer times to product.
The creative programming group is typically in charge of maintenance and customization. With some exception, work is typically one or two off, with a great pressure to reduce the time needed for same. These operations typically have programmers who are known for expertise in very specialized areas, and management applies these folks in a triage fashion, in order to cover the greatest portion of customer needs. Little tracking is done, sometimes not even billing, and the software that exits this process is a creative work by an individual. Like all such works, the production cost is highly variable, and depends on a huge number of factors, most of which are untrackable. The software does, however, come out of the process in record time (if done right) and usually fits a single situation as well as possible.
The trick is determining which kind of organisation to use for a given project. Long and short term goals need to be evaluated to decide this.
Be sure to use appropriate measures, as well. Estimates and schedules are approriate measures for the designed type, but don't work for the creative type. Consider using alternate measurements, such as differing timescale/costs depending on the individuals that handle the project, or internal bidding.
What I do know for certain is: Communicate everything to everybody, even if it means reduced revenues. I hate to say it, but I have seen a lot more marketing types ruin projects by giving customers unrealistic expectations than engineers and programmers. Marketers must know what is possible and what is not, and have the common decency to stand up in front of the customer and say "our product doesn't do that. Let me check if it's possible..." even if it means losing the sale.
very simple (Score:1)
Triple the time. Double the money. Now you have a pretty good estimate.
If, by some freak chance, the project finishes under-time and under-budget, then management will be happy. If it's ON time and on budget, management will be happy.
my suggestion (Score:2)
Awareness of the non-engineers' interpretation (Score:4)
I have a guy on my team who very frequently answers questions with "Sure, that's easy, take me 2 seconds." Most often what that means is "I have an idea how I would do this." And then later, when the time is significantly greater than 2 seconds, it becomes "Well, yeah, if the so-n-so had worked the way it was supposed to, blah blah.." The art of the estimate is in being able to make allowances for things not working properly, since experience shows that they never do.
For a long time I was the guy that management feared taking into meetings because I answered all questions with "Yes". Of course, what I meant was "Yes, that can be done given adequate time and resources. It is technologically possible to do the thing you have asked of me." And of course my managers knew that that's NOT what marketing meant, they meant "Can we have it in reasonable time?" Reasonable being subject to interpretation, and not mine -- I didn't offer opinions on what was reasonable, I just said if it was possible.
Of course, the problem works in both directions. I know of a certain project manager who, when an engineer provides an estimate, is always the first one to say "Could I double that for QA?" It's quite possible (though unlikely! :)) that the developer in question has already factored that in. But, since he can't be sure, he has to play it conservative, and we end up taking 6 weeks for things that should really take 1 or 2.
Since becoming a manager (eep!) I've amended my logic and I now share it with my reports: "All things are technologically possible given infinite time and resources, therefore it doesn't make sense that somebody is asking you that. What they're asking is something is possible given real time and resources, so you need to factor in those variables."
Duane
(Once, at a meeting, a manager told me that I wasn't allowed to open my mouth unless the word coming out of it was "no". So I listened patiently as a marketing guy said "We were thinking that we could do X, Y and Z. Would that be a problem?" So I looked at him, looked at my manager, looked at the marketing guy and said "No.")
Some thoughts for marketing... (Score:1)
First, don't ask for an estimate until the engineers have some ideas regarding a design, especially if they haven't done something like this before. It's nearly impossible to figure out how long a task is going to take until the engineers have had a chance to think about it for a bit.
(And, btw, don't presume to know what should be simple, "with no new technologies". If it really is, then the engineers will figure out that they've "been there, done that," without having that dictated to them.)
In many larger projects, there typically is a designated project lead, who is responsible for gathering and tracking project schedules, and should be technical enough to know when a given estimate is too low (or too padded). That should be your point of contact. Let them gather the estimates.
Also, make sure your product requirements are VERY specific, VERY clear and VERY complete BEFORE you ask for an estimate. Often, the engineers won't give an estimate because they have no idea what marketing wants in the first place, because the published requirements are far too vague and/or incomplete. I've worked on projects where no one thought of how anyone was supposed to support the software once it was running (and where developing the necessary tools added about eight weeks to the schedule, much to the chagrin of the business types).
Finally, even if you don't think you're going to get a usable estimate from the engineers, ask anyways. If you set a schedule without the input of the technical staff, they definitely will feel more free to blow off your estimates, since they didn't buy into it in the first place.
Re:my suggestion (Score:1)
liason role for project manager (Score:2)
If you choose someone with a foot in both camps and who can encourage the coders to optimal productivity while staving off new features, you'll be pretty happy with the result. And even when things go badly, people who don't really speak the same language have someone who can interpret for them. The real thing I've heard everyone screaming for is information.
This is the true role of the project manager. And more than one project can share the project manager, so it's not a hideous resource sink.
Simple (Score:2)
simple. (Score:1)
Estimate from techies to complete the project : T
Double for QA time : 2T
Add 50% for techies quake sessions : 2.5*T
Add 10% for peace of mind : (2.5*T)+(0.1*T)
Thats your project schedule.
Re:Here's a novel concept... (Score:2)
But here's a good reason not to market a product before it's finished. If it's replacing a current version, sales of your current version will dry up as soon as a new version is announced. And then there's a mad rush, clueless managers running 'round like chooks with their heads cut off, and the development team get stuck in the middle.
No, I say keep quiet about a product until a solid beta version is produced -- as in a version of the software you would consider selling, but would like more real world testing (not a version that's still got heaps of known bugs). Transmeta is probably a good example of how to market stuff in a way that keeps the developers sane.
Marketing has its problems -- I'm an insider (Score:4)
I'm a geek who went marketing. I started off in QA, went into development and program design, and then jumped ship to product management.
I was fortunate enough to have the opportunity to take a course from Pragmatic Marketing [pragmaticmarketing.com], who are a group of consultants who teach product management in the high-tech field. I'll very quickly summarize some of their concepts, but I'd advise anyone in tech marketing and senior developers who work with marketing to take this course.
The primary thing to understand is that there is no magic equation that will accurately predict time. Steve Johnson, one of the consultants at Pragmatic, said that in his experience, it's best to let development control the schedule. In return, marketing controls the features.
See, generally speaking, most marketing people pick development schedules out of the air. All the marketing folk want to put new products out for a major industry tradeshow, regardless of when they start. This doesn't work, since when you start has a major impact on when development will finish.
In the Pragmatic scheme of things, the marketing person comes in as the expert on the market. (Note: Pragmatic has a bunch of tactics to teach marketing people how to do this.) The development person comes in as the expert on technology.
The marketing person then brings up a set of prospect problems. That is, they the talk to people they want to sell to, and find out what their problems are. The development person takes these problems and works out some ideas for technical solutions, and then comes back and says that if I have X developers and Y months, I could build something that solves all these problems.
Then they bargain over what problems they could solve in how much time. As the expert on the market, marketing should know which problems are the most important. As the technology expert, development should know which solutions are easy to build. Between the two, they work something out, write it up on paper, and stick with that. Should something come up which changes the schedule, they renegotiate.
Marketing, therefore, should not pretend to know anything about the technology or the time to implement it -- they aren't the experts. Development should not make assumptions on what the market wants or what the product needs -- they aren't the experts either.
It's hard to work things out based on a spec, since specs often gets so voluminious and complicated that you lose sight of what you're actually trying to do. It's easier to work things out based on problems, since they are concise and easy for both sides to understand.
There is a LOT more to it than this. Pragmatic actually has an entire course called Working with Development -- it's worth every penny.
I have the coolest job... (Score:1)
My Thoughts.... (Score:3)
Second, go through the prototype, and repeat step one and two until you get a prototype that you like (see the end of this for clarification). This determines if the project is worth pursuing. There's three estimates you need here. The first is the estimate of how long it'll take to complete WITHOUT ANYTHING NEW the prototype. More simply, if you were to move the prototype to production, what would it take?
Third, there is the estimate for the additional features not included in the prototype, but that were included in the original design request.
Fourth, is the scope creep stage. This is where you throw in the new features you want, or where you refine previous ideas. Most items in this list are probably best left for future projects, or should be smaller projects in and of themselves.
This is exactly the method the auto industry uses. The managers say they want a car that looks like or does X. The designers go draw up a few things, and take it back to the bosses, and incorporate feedback. This all continues until the bosses see something they like.
At this point, you're up to step three, which is what would it take to bring what's been drawn to the market. Extras, options, available colors, interior materials, performance packages, and all that are not part of this project. They are extras. They are side-pieces that integrate into the final product, but are not necessary. You can build a sell a car that lacks air conditioning and a radio.
After this comes step four, which is the iterative/derivative models. Volkswagen is just bringing their step four products, the new turbonium, and the new four-wheel drive Beetle, to market. Neither of these was in the original design specification, but they are both offspring of the Beetle.
Lastly, understand that programming and farming are similar endeavours. Some years you make money, and have a bountiful harvest. Other years, nothing goes right. You can force extra food out of the ground, but it takes significantly more inputs, and even then you may not get all you wanted.
Good books (Score:2)
In this case, Chapter 8, Estimation is the one you're after. It mentions:
He then goes on to talk about what factors influence accuracy, why so many projects are bad at it, and what all parties can do to improve schedule accuracy.
In my experience, these are the three biggest problems:
- Poorly defined scope - Someone will say "We need a little web site to do X, Y, and Z." But everybody will be in too much of a hurry to figure out what 'little' means, or what the various features really imply. The result is either a late but satifactory product or an on-time but inadequate product.
- Customer ignores realities of development - Often a customer or boss will say, "Build a site with these features using three people in three months or less." This specifies 1) requirements, 2) resources, and 3) time. This ignores the realities of development. A customer should be allowed to pick any two of those three; the developer must be allowed to use her experience to estimate the third.
- Single-shot development - Much software, and especially modern web sites, can be developed incrementally. It's very dangerous to cook up a plan and send the developers into a back room for six months, hoping they'll come out with the perfect product. It's much less risky to use an iterative development process, where they come out with new versions every few weeks.
I also recommend his book The Software Project Survival Guide [amazon.com]; for non-techies, it's much less intimidating than Rapid Development.And for the serious developers out there, I encourage y'all to take a look at Extreme Programming [amazon.com]; I don't buy all of it, but it's very thought provoking, and you'll certainly end up using some of its methods.
User Friendly (Score:1)
My thoughts.. (Score:2)
First of all, I can't entirely agree with the bunch of people saying "you can never be sure, every bit of programming involves creating something that has never been created before", etc. Remember that the vast majority of programming that gets done in the world is in-house corporate stuff. I did that for 5 years, and believe me, there ARE a lot of what Chris describes as "normal" projects. Database, various input and update screens/pages, enquiries, reports, etc.
Now, fair enough, Chris is talking about a company with marketroids, so I guess we're not on the corporate in-house track. But maybe he means a sort of "service" model of programming, not producing programs for the open market, but for particular clients. This would definitely explain the marketroids need for accurate deadlines and costings, and also be a situation where lots of fairly straightforward projects are being churned through.
These CAN be estimated pretty accurately, but it needs a senior programmer/project manager who is both skilled in making estimations, and familiar with the team, the tools and the situation. If you've got such a guy, then everything everyone else said applies - you gotta let him estimate, trust his estimates, don't just ignore them if they don't fit your business plan, don't change the requirements halfway through without redoing the schedule, etc. etc.
Real development of software for the open market is a whole different ballgame. Sure, there's people who are good at estimating, people who are terrible, but what it boils down to is that you ARE likely to be dealing with unpredictable situations - people ARE creating something new that has never been created before (hopefully!). So schedules will go wrong.
The way we [datastream.com] deal with this is that marketting come up with a list of desired features, we try to make a rough estimate of effort, they throw away the ones that are low importance/high effort, we come up with a rough schedule of what will be in the product and how long it will take. If this is too long, some of the features get dropped. But - and this is the important bit - the features that remain are ranked in order of importance, and we work on the important ones first. That way, if things go wrong and the schedule slips, marketing can make the call as to whether to put off some features until the next version, or put back the release date.
Caveat - this is to do with producing new versions of well-established products. If it's a whole new product developed from scratch you probably won't be able to drop features halfway without wasting any effort on them, because you'll have to do your architecture in such a way as to support them. But I'm sure the same basic marketting/programming relationship can be applied..
Here's a novel concept... (Score:3)
Do you think programmers enjoy saying they can't give you a firm time to completion? The amount of shit we get over it drives us up the wall. Every new peice of software includes something that's never been done before. Stuff that's never been done before can not be accurately predicted.
Re:my suggestion (Score:1)
Not true -- a programmer would simply count from 0-9, rather than from 1-10. However, the programmer would conclude that both taking 10 paces leads to a race condition -- you can't be certain who will get to fire first, and will thus optimize out the unnecessary delay loop, and will turn and fire immediately :-)
Re:Here's a novel concept... (Score:1)