My Cure for Overambitious Projects

You’ve probably encountered clients that request an unrealistic amount of features to be included in a product. They’ll start by listing a few features that the product “absolutely must have,” which suddenly reminds them of a few more features, which then brings up more that “we probably should include.”

Meanwhile, your headache is growing because you know that such lofty expectations always fail.

Well, it’s time like this, before any of the development begins, that you’d benefit from splitting up feature requirements into two categories: essential and supplementary.

This simple action will save you enormous stress later on in the development process, because it forces both you and the client to agree on what is most important, and what can wait.

After you make the list, give a copy to your client, and keep one for yourself. Whenever an issue about including more features comes up, refer to the list and ask, “Is this truly necessary?”

-Judi

Some More Comments on Overambitious Projects

I previously asked readers to share their experiences with overambitious projects. Here were some of the replies:

Creative people always desire to create a perfect product. And it is very difficult to stop perfecting it… It’s not easy to differentiate between essential and supplementary features.

Also interesting fact from the “big science” molecular biology – the Human Genome project (that was also saturated with computation and programming). Finishing sequencing took as much time as the first 90% of sequencing work.

So true. There's an understandable amount of pride that creatives and entrepreneurs feel about their work--sometimes to their detriment.

And also this suggestion on how to handle feature-hungry clients

As a product manager, I have dealt with this issue many times.  It always helps to ask the client (internal or external) to estimate the additional sales that will occur if the new feature is added.  Invariably they either realize the answer is zero, or understand they have no way to credibly answer. No additional sales, no money for development. Simple but effective.

What a fantastic idea. It lets the client clearly see the value of each additional requirement.

-Judi

Build or Buy? How to know if you need custom software

I met a woman yesterday who asked me if we could build some software for her business. I told her yes, we could, but it probably wouldn’t make sense. Let me explain.

Building custom software is an investment, and that investment usually doesn’t make sense unless you’re going to sell multiple copies of the software, or it’s going to give you a significant competitive advantage in your business. And I do mean significant.

For example, I spoke with a company not too long ago that was thinking about developing some software to help them with an internal business process. They had done their research, and there were packages on the market, but they didn’t exactly meet their needs. I spent enough time with them to give them a ball park quote, and it turns out the custom solution was seven times more expensive than the off-the-shelf solution. Frankly, this isn’t even a lot. Think about it – if the vender of the generic solution spent the same amount of money developing their solution, they would only need to sell seven copies to break even. I realize it’s more complicated than this, there’s distribution, support, marketing, overhead, etc. but what if they sold 70 copies? You can see how this kind of investment could pay off. And if they sold 700 – wow!

So this company decided to buy the off-the-shelf product that met most of their needs. In my opinion, that was the right decision. It only makes sense to build custom software for internal use when you can get a significant competitive advantage. Before you think about investing in custom software, look at what’s already on the market to meet your needs. It may not meet all of your needs, or meet them perfectly, but ask yourself how much would it be worth to have that perfect solution? Would I be willing to pay ten times the cost of this package? More? Often the answer will be no, and in that case, just find the product that meets your needs the best or allows you some ability to customize.

Want to develop a new product? Where do you start?

I’ve been working with a lot of companies lately that have never developed a new product from scratch. They all seem to have the same question – “Where do I start?”

The answer is always the same – with requirements, and by requirements I don’t mean a bullet list of features, although that’s a start. By requirements, I mean detailed requirements of what you want the product to do and how it should behave in every situation. Error conditions are one thing that’s typically forgotten. Requirements are also not necessarily functional, for example, the maximum (or target) manufacturing cost is a common, and commonly overlooked, requirement for an embedded system. They say the “devil’s in the details.” In this case, that’s true.

The first question clients have (well, maybe it’s not the first, but it’s the big one everyone wants to know) is “how much will this cost?” Without the kind of detailed requirements I’m talking about, it’s impossible to give any kind of meaningful estimate. That’s why we’ve had such great success creating an initial engagement that delivers requirements and a rough estimate of time and cost. This initial engagement typically lasts between a week and a month, depending on the scope and complexity of the project and gives the client accurate information that they can use to make decisions. We usually find areas of trade-off, like features that could be in a future release, and can balance the client’s time to market and budget needs.

So remember, next time you have a new product you’re developing. Details, details, details!

What it Takes to be a Successful Consultant

I have not written for a while on what it takes to be a successful consultant, but lately I’ve been noticing some common trends with our best people, and oddly enough it has absolutely nothing to do with their technical abilities. I’m really not sure what to call it – grace, poise, or just plain old fashioned professionalism.

In one instance, one of our clients handled an HR problem, let’s just say, in a less than optimal fashion. Our consultants there were affected by this decision, and one of them could have been justified to be hurt or angry, but to his credit, he just continued to do his job while the storm raged around him. He happened to be in our office one day while this was going on and his comment to me was “I have a job to do, and I’m going to focus on that and do my best.” Love that!!

In the second instance one of our consultants was working with an engineer at our client’s client on an integration project. I’ll spare you the gory details but this engineer was engaging in programming practices that would make any professional programmer shudder with disgust. The stories even made me shudder and I haven’t been a programmer in ages! To his credit, our guy worked thru the issues with this engineer without issue.

Although they’re all sharp, in fact some of the smartest people I know, I think I admire the restraint, respect and professionalism our consultants exhibit even more than their technical chops. We serve at the request of our clients, and being difficult or disrespectful does nothing for our relationships. I’m so proud to be a part of this team, with these amazing engineers and developers!

Software Process Improvement Consulting

In 2005, I joined Advanced Decisions to establish a Software Process Improvement practice within the company. Well, long story short, I got busy with our core business of software and hardware product development and we never formally developed that practice. The interesting thing is that we seem to provide consulting on Software Process and SDLC as part of many of our engagements anyway.

The most obvious example is our work with start-ups. We typically are engaged to develop their product, but often wind up developing their process, their team, and even on occasion aspects of their business. With our larger clients we develop good quality documentation that’s often used as an example of what to develop in the future. Even with our prospects, we ask them enough questions about how they are developing their products to get them thinking.

It just goes to show, the outcome of a goal or desire may not always look like you expect.

How to tell your customers they’re wrong

We often find ourselves telling our clients they’re wrong. Of course, we don’t say it like that – “You’re Wrong! Mr. Client!” No.

Sometimes they have a problem and already have a solution in mind. Our engineers can often tell very quickly their solution is not going to fix their problem. These discussions are usually easy. The engineers can come up with better solutions and it’s obvious we’re working in our customers’ best interests.

But what if you think they’re solving the wrong problem? This is a much more difficult conversation. Especially, if they are passionate about solving a problem that you don’t think is a problem. Maybe you’re not the one having this problem, but other’s are. Maybe they’d appreciate the solution. Who’s to know?

I heard a great suggestion on how to handle this just the other day (Thanks CS!). I love it because it’s open, and honest, and all about starting the relationship off right. Just ask – at the beginning of the relationship, or conversation, or wherever you happen to find yourself, just ask if they’re open to questions about their assumptions if you hear something that does not make sense. It might sound something like this “You know, Mr. Customer, sometimes I’m talking with other CEOs and they say things that just don’t make sense, they find it very helpful when I question these statements. Is that something you would find valuable?” I’d be shocked to get a no, but whether they say yes, or no, at least you know where you stand. And who know, you may just learn something.

The Life of a Consultant

I had lunch today with one of the smartest people I know (no, I didn’t have lunch alone!).

He’s a software architect for a large global financial services firm and has found himself with an interesting job – he’s the “go to” guy for all of their most difficult software challenges. He referred to these projects as simultaneously repulsive and fascinating. He and his small team of equally brilliant people move from project to project – usually the ones that no one else want to take on, and unsurprisingly (to me at least) they are successful at solving these seemingly impossible problems.

The thing I found most interesting, is that the things he likes about his job are exactly what our consultants like about consulting: New challenges all the time; staying up to date on cutting edge technologies; and focusing on new design as opposed to maintenance.

I know this kind of group, (architecture, special projects, internal professional services, etc) exists within many big companies. This could be an alternative for engineers and programmers that crave the challenges and variety of the consulting life. Anyone have any experiences working in this kind of a group? What do you think?

Proposal Writing: What Do Clients Really Want? (Learning from our Failures)

OK, “failure” is kind of a strong word in this case. But here’s the story: We recently had the opportunity to do a “post mortem” kind of meeting on a deal we didn’t get (hey, you can’t win them all, right?) We thought we knew why, or had some ideas at least, but we wanted to find out for sure.

The client was generous enough to give us an hour of his time, and honest enough to give us really candid and open feedback. So what did we learn? Some of the things we had assumed were true, but there were others. The one that resonated most for me is the Business version of the grammar school advice to “Show your work”.

Our team had spent hours discussing this project, formulating an approach, and really drilling down into the details. In an effort (and it did take some effort) to make a clear proposal, we eliminated all the details behind our recommendations. Unfortunately the client interpreted that as a lack of analysis, and why not – he didn’t see it, so in his world it didn’t exist.

This really hit home for me. I was always a proponent of the short, sweet, clear proposal. I don’t’ know about others but I typically don’t want to read 20 pages of what someone thinks, but (ha – fortunately :-) ) not everyone is like me. Looking back it seems obvious that we should have included all the “sausage making details”, perhaps as an appendix or perhaps in the main proposal with an executive summary. I’m curious, what do others do?

Advanced Decisions is 40!

Advanced Decisions is turning 40 this year. That’s amazing to me. I’ve been spending some time thinking about what’s lead to this longevity and the one thing I keep coming back to is relationships.

We have customers we’ve been doing business with for 20+ years. In such a crowded marketplace, they have many choices, but have formed bonds with us and trust us. Even when the individuals change companies, they still remember and call us. We recently got introduced to a brand new company in just this manner.

We also have employees that we’ve known for close to 20 years. They’re our “go to” people. When we have a tough challenge we immediately think of Brad, or Jose, or Linda, or Dave, or many of the others we’ve worked with “forever”.

We even have service providers that we’ve known for that long. In fact, the company that does our internal IT troubleshooting is owned by one of my very first mentors, way back when I was a Northeastern co-op student working at Pitney Bowes.

The continuity of these relationships is comforting and stable, but would be boring if not for the new – the new employees like Zach, Jovin and Joanne, the new clients like ClearView Edge and Wilkes, the new vendors like Response and many others who keep us growing and evolving even as we retain our “roots”.

I’m incredibly grateful for the presence of those that have been part of Advanced Decisions’ success, whether for 20 years or 2 months. I hope you all can come and celebrate with us on Thursday May 13th here at our offices. To another 40!!!

Is Contingent Staffing a trend?

I read an article today that talked about Contingent Staffing, which they defined as the use of temporary or freelance labor, as a trend. I don’t agree with this. This is nothing new; companies have been doing this forever. I think what we’re seeing is a cycle. We have noticed in our business when the economy is booming companies want to hire full time people, to minimize the “brain drain” when the contingent folks leave, and impacts in internal morale from hiring them in the first place. In 2004-2006, we were seeing far more opportunities for full time placements than consulting engagements. Conversely, when the economy struggles, companies still want to complete their projects so they hire temporary or contract labor, as their doing now. I suspect in the coming years, we’ll see the pendulum move back towards a more balanced approach of full time people and contract, temporary or contingent workers.

What do you think?

Keys to a Successful Development Project

I was reading an article about startups recently and the author claimed that success was not due to one big thing, but a lot of little things. We had a business coach a few years back that said the same thing – when we reach the level of success we’re aiming for we won’t be able to look back and put our finger on one thing, but instead, we’ll see it was many little things contributing and working together.

It got me thinking – is that true of software projects as well? Probably. This may be one of those universal laws like the Pareto principal (aka the 80-20 rule), that seems to apply to everything.

Is there one thing, one big key that will make a project successful? If I had to pick only one, I would say it would be the team, but is that enough? I don’t think so. Even the greatest team can’t be successful with a lousy idea, bad requirements or no funding. Sure they may be able to get something out the door, but will it sell in the marketplace? Will it really meet a need? Probably not.

Ok, so I guess we’ve established that I don’t believe in “silver bullets”. So back to the original premise – what are all those little things? Well certainly the team, but what about tools, processes, appropriate budgets, management support, a great idea, customer need, stellar marketing, support, sales, etc……

It really does take a village!

What does a software developer need to begin design?

Too many projects begin without even a hint of a written understanding about what is to be built. Unfortunately many of us have been there and lived through the pain of redesign and project slippage. At the other end of the spectrum some write suffocatingly detailed Requirements Documents. Masterpieces of literature that developers and managers don’t actually understand if they read it all! As in the case of no written requirements, the project usually ends up in the same predicament --- redesign, rework and missed opportunity.

In my experience developing embedded systems or software applications the big picture requirements must be spelled out. They should contain at a minimum the following: performance goals, safety factors, Human-Machine Interaction, testability, external interfaces, deployment, and target cost for hardware designs.

Defining the products requirements does not have to take a very long time. I find that in most cases this phase should take on average 2 - 4 weeks working collaboratively with the major stake holders.

The important point to keep in mind is that the requirements document must be be in a form that is easily understood by the technical team as well as non-technical management. Keep it as jargon free as possible. Define all terms.

INCLUDE PICTURES!

For example, an excellent way to define the user interface level independent of the actual technology used are pictures. It is more effective to draw a screen or touch panel then to try to describe it. Even more effective, use a rapid prototype application to create a demonstration of application. This is the most effective way to create a common vision between developer and manager of the look and feel of the resultant product. Be sure to include one or more block diagrams to illustrate the system and interfaces.

The next time you start a project please don’t settle for 10 bullets on a napkin!

Don't Forget to Listen

Whether you’re in Consulting or in a Consultative Sales Role, it’s so important to REALLY, REALLY LISTEN! I know, this is Sales 101, but I’ve had so many experiences lately where people (consultants and sales people) were far more interested in pushing their own agenda – whether the customer wanted it or not. I know when it’s happened to me, it’s completely turned me off. Even if these people have wonderful services or products to offer, it’s not likely I’m going to be interested.

Full Process Review or Quick Fix?

Lately we seem to have so many consultants interviewing for so many opportunities it's hard to keep track of all the details. We do have some tools in place but they're not enough. When the "pain" gets to be too much we've been creating quick fixes to relive the particular difficulty we're having at the moment.

In a casual hallway conversation, we were just about to do this again, when it dawned on me that we had not really looked at our end-to-end process and inter-relationships between Sales and Consultant Services in a while. Certainly not since our business volume has picked up. My Software Development background kicked in and I suggested we take a step back and do just that.

I know that when we're moving so fast, it can be tempting to just address the immediate issue, but sometime a more holistic approach is the way to go. The trick is in knowing the difference. I think, just like in Software Development too many quick fixed can create a mess really quickly. In this case, we had been doing the quick fix thing for a while and it just seemed like time to look at the big picture.

You haven’t worked in our Industry

Here is a question I hear when working with new clients in different industries. How can you help us if you don’t know our market? Over the years I have tried to be vertical market agnostic in the pursuit of technology solutions. So when I come across this question I am ready.

My reaction is that domain knowledge does matter however the application of technologies that work to solve similar problems in different industries could be just as helpful. I find that just by mentioning a related problem encountered elsewhere and discussing how we solved it and the technologies used really brings the client on-board fast.

Technologies come and go quickly, much faster than typical product innovations. Companies used to certain communication mechanisms or display devices may not see the exciting changes happening. Certainly not all technologies are applicable in every market however many are and the challenge is to choose carefully.