Is the buying cycle different for services vs. goods?

I’m a shopper. It’s not that I like to shop, but when I do, I tend to shop around, read reviews, decide what I want then try to find the best price. But – that’s only for goods – computers, printers, cell phones, cars, an oven, etc. I recently noticed when shopping for services (or hiring which is kind of like shopping for services) I tend to make decisions MUCH differently. The funny thing is that I make those decisions much more quickly with much less comparison shopping, even when the dollar value is higher.

One example – we recently hired a marketing agency (Response Marketing – check them out they’re awesome!) and although my business partner and I had not intended on hiring them, or any other marketing agency, we had made our decision before our contact had gotten into the elevator. Now, we both know of many other agencies and sole practitioners, so why didn’t we shop around? Easy – we like and trusted the owner of this firm, we were comfortable with the price, and we believed that they could help us.

I find comparison shopping for services to be somewhat problematic. After all, you can’t assume that a $100/hour service provider is better, worse, or the same than a $150/hour service provider. It has everything to do with the person or company and their process, and if you feel comfortable with them. On the other hand, an iPhone 3Gs with 16 GB is an iPhone 3Gs w/ 16 GB (not that you’re going to get a deal on that). When shopping for a service provider, I want someone I am confident is going to do an excellent job. On goods – I still love a good deal!

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!

Feast or Famine in Software Development Organizations?

In so many areas of my life I go thru these cycles of feast or famine – social engagements, work load, car problems, what have you. I either have lots or none, or is that just my perception?

There’s one area that I can think of in which I’ve never had this problem – the software development organizations I’ve been a part of. Sure, we’ve had that with bugs, or turnover, but never, ever, ever workload. There was ALWAYS more than enough work to do. Maybe it’s just the nature of the beast – companies always want to improve their products and there are a wealth of ideas on how to do that. It’s also a positive thing. I love being busy, and if a company can not keep it’s developers busy, why does it need them?

The downside however can be a feeling of overwhelm, or inefficiencies, or continual long, long weeks. What kinds of things can we do to smooth this out a bit, or at least mitigate the negatives? I have some ideas:

1) Prioritization – so many organizations are SO bad at this. The priority is the priority of the moment, based on the loudest customer, one data point, or the whim of an executive. A well thought out prioritization can allow your development teams to get more done, just by finishing what they’re already working on. I’m not saying it should never change, but it certainly should change less frequently than you change your clothes.
2) Focus – knowing the big picture will help with number 1, as well as with coherency of design and team morale. If you’re building something to do x, don’t try to do y. Pick one thing (at least to start) and do it exceptionally well
3) Learn to say “No” – I find that people (not just in development organizations) spend an inordinate amount of time exploring roads not taken, as in “maybe we should have done x”. I once heard a speaker call this “Killing the un-chosen alternative.” I like that, and not because I’m violent – I’m not. I like it because it allows you to devote 110% of your attention to being successful on the path chosen and stop second-guessing yourself, a time wasting distraction if there ever was one.

I for one hope there isn’t a famine of new product ideas or developers to carry them out. Let’s just try to do it sanely.

Self-regulation in Software Development

Senia Maymin (I can’t link to her website for some reason – I’ll update this when I can) has written a bunch about a concept called Self-Regulation. This concept fascinates me. It’s one of those things that’s simple – particularly to understand, but certainly not easy. It’s the skill that you use to do the things you need to or should do. The idea is that self-regulation is like a muscle and the more you use it (in any area) the stronger it gets (in every area.)

It’s easy to see how it applies to my life – go to the gym, make my sales calls, blog, etc. I always thought that once you did those things and saw the benefits, you’d do them again BECAUSE you saw the benefits, but the way she talks about it, it’s less intellectual than that. The more you do these things, the easier it is to do other things. But how does it apply to the field of Software Development?

It’s easy to see the areas where you might need self-regulation, testing, documentation, and perhaps for some, design. Does this mean that if you make yourself do a good thorough design it will be easier to make yourself do the testing or documentation? Well, it’s certainly easier to do those activities for a well designed system, but is it easier to get yourself motivated to do them? Interesting question – I really don’t know…

Partnering with other engineering firms

We’ve been interested in partnering with other engineering firms, but have never quite made it work. I’m not exactly sure why, but looking back, I’m not sure all the previous attempts have been true partnerships. We’ve been approached by a few firms recently, so it’s got me thinking about it again.

It seems like it would be a good idea. We often have consulting jobs and don’t have the right person, and occasionally we have a consultant free that may be able to do a job for another firm. In this economy, it makes sense to maximize any opportunity, and by working with other firms, you can expand your network and broaden your offerings.

So what would a perfect partner look like? Well, first of all there would be some commonalities. For example it makes more sense for us to partner with someone working in product development than say distribution. Second, there should be some extension of services. We’ve met a great mechanical design firm in the past, which could be a great potential partner. We do very little of that, and they do very little software and hardware design. Finally, there needs to be common values. We would never consider partnering with a firm that did shoddy work or engaged in unsavory (in our opinion) business practices.

I’m looking forward finding those good fits. I guess with anything, patience is key.