How Can Marketing And Techies Best Work Together?

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?

Comments

Accurate costing and schedules ARE possible.

[human bean]

But only if the project/operation is structured in an engineered way. Allow me to explain:

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.

Awareness of the non-engineers' interpretation

[dmorin]

I think one of the biggest communications problems I've seen between the groups is that most developers I know, when asked for an estimate, will answer something like "3 people 2 weeks". But what that really means to them is "3 programmers will have the code running in 2 weeks." It does not take into considering project managers, or support staff. Nor does it count QA time, or time to negotiate licensing with the third party vendor, or write the project agreement, and so on.

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.")

Marketing has its problems -- I'm an insider

[RhetoricalQuestion]

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, 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.