I have been a self-employed software consultant for over 25 years. Quite often, folks wanting to become independent consultants have asked me how to get started. “How do you get the word out?” “How do you market yourself?” These are usually the most asked questions.

Rather than go into a long, time-consuming essay about the ins and outs of promoting oneself, here are thirteen basic ideas you can use that will go a long way toward promoting yourself as an independent consultant of any kind.  Try one or try them all.  Whatever works for you is what counts.

1              Give people two business cards instead of one.  Ask them to pass the extra one along to a friend or business associate.

2              Build word-of-mouth referrals by creating flyers with inserts offering promotional discounts.  Ask owners of your local dry cleaners, hair salons, and restaurants to distribute thyem in exchange for bigger discounts on your products or services.

3              Hire a native speaker to rewrite your materials into other languages.   This way you attract a wider and more diverse audience while expressing your message properly, and showing respect for everyone’s holidays, ceremonies, and culture.

4              Send thank-you letters to every customer, vendor, or supplier three or four times a year.  This will remind them that you are still operating and could result in new sales.

5              After mailing flyers, brochures, etc., follow up by telephoning customers or prospects.  Often, this type of personal contact results in a boost in your business.

6              Listen to what your clients or customers tell you about your work.  When appropriate, ask what new services or products you could provide for them.

7              Consider giving something away.  Donate your time or even a modest gift, coupon, or discount.  It’s a great way to warm up potential customers.

8              Teach classes, give presentations, write a blog, create an e-mail newsletter, or write short articles for your local newspaper.  You can showcase your skills and gain free publicity.

9              Do something good for others in your community.  Participating in funding drives that allow you to mingle with others and become acquainted with new groups in your community.

10           Keep up-to-date with the latest technologies in your field.  Investigate the hidden value of online advertising by browsing web sites and subscribing to e-mail newsletters.  Consider these to be investments in your future and a source for potential marketing ideas.

11           Continue your education and stay current on economic and technological trends.  Attend conferences, seminars, workshops, and join industry organizations and user groups.

12           Get out of the office at least once a day.  Meet a colleague for breakfast or lunch, and wherever you go, talk with as many people as possible. Don’t forget to always have a generous supply of your business cards, wherever your go.

13           Nurture and enjoy your dreams.  They are too precious to abandon.

Software development projects fail when they do not meet the following criteria for success:

  • It is delivered on time.
  • Itcomes in on or under budget.
  • It works as required. 

Only a few projects achieve all three. Many more are delivered which fail on one or more of these criteria, and a substantial number are cancelled having failed badly.

So what are the key factors for success? Organizations and individuals have studied a number of projects that have both succeeded and failed and some common factors emerge. A key finding is that there is no single overriding factor that causes project failure. A number of factors are involved in any particular project failure, some of which interact with each other. Here are some of the most important reasons for failure.

Lack of User Involvement

Lack of user involvement has proved fatal for many projects. Without user involvement, nobody in the business feels committed to a system, and can even be hostile to it. If a project is to be a success senior management and users need to be involved from the start, and continuously throughout the development. This requires time and effort, and when the people in a business are already stretched, finding time for a new project is not high on their priorities. Therefore senior management need to continuously support the project to make it clear to staff it is a priority.

Long or Unrealistic Time Scales

Long timescales for a project have led to systems being delivered for products and services no longer in use by an organization. The key recommendation is that project timescales should be short, which means that larger systems should be split into separate projects. There are always problems with this approach, but the benefits of doing so are considerable.

Many managers are well aware of the need for fast delivery, leading to the other problem of unrealistic timescales. These are set without considering the volume of work that needs to be done to ensure delivery. As a result, these systems are either delivered late or only have a fraction of the facilities that were asked for. The recommendation here is to review all project plans to see if they are realistic, and to challenge the participants to express any reservations they may have with it.

Poor or No Requirements

Many projects have high level, vague, and generally unhelpful requirements. This has led to cases where the developers, having no input from the users, build what they believe is needed, without having any real knowledge of the business. Inevitably, when the system is delivered business users say it does not do what they need it to. This is closely linked to lack of user involvement, but goes beyond it. Users must know what it is they want, and be able to specify it precisely. As non-IT specialists, this means normally they need skills training.

Scope Creep

Scope is the overall view of what a system will deliver. Scope creep is the insidious growth in the scale of a system during the life of a project. As an example for a system which will hold customer records, it is then decided it will also deal with customer bills, then these bills will be provided on the Internet, and so on and so forth. All the functionality will have to be delivered at one time, therefore affecting time scales, and all will have to have detailed requirements. This is a management issue closely related to change control. Management must be realistic about what is it they want and when, and stick to it.

No Change Control System

Despite everything businesses change, and change is happening at a faster rate then ever before. It is not realistic to expect no change in requirements while a system is being built. However, uncontrolled changes play havoc with a system under development, and have caused many project failures.

This emphasizes the advantages of shorter timescales and a phased approach to building systems, so that change has less chance to affect development. Nonetheless, change must be managed like any other factor of business. The business must evaluate the effects of any changed requirements on the timescale, cost and risk of project. Change Management and its sister discipline of Configuration Management are skills that can be taught.

Poor Testing

The developers will do a great deal of testing during development, but eventually the users must run acceptance tests to see if the system meets the business requirements. However, acceptance testing often fails to catch many faults before a system goes live because:

• Poor requirements which cannot be tested 
• Poorly, or non planned tests meaning that the system is not methodically checked 
• Inadequately trained users who do not know what the purpose of testing is 
• Inadequate time to perform tests as the project is late 

Users, in order to build their confidence with a system, and to utilize their experience of the business, should do the acceptance testing. To do so they need good testable requirements, well designed and planned tests, be adequately trained, and have sufficient time to achieve the testing objectives.

Conclusion

These six factors are not the only ones that affect the success or failure of a project, but in many studies and reports, they appear near, or at the top of the list. They are all interlinked, but as can be seen they are not technical issues, but management and training ones. This supports the idea that IT projects should be treated as business projects.

Nevertheless, the technological developments that Apple produced over the years have caused the world of computing to lurch in directions that were not anticipated by the group of connected people who were considered “those in the know”. We who are not in the Apple camp have been affected by these developments, and have had to adapt to new paradigms over the course of our careers. This is primarily because of the taste, the will, and the drive of one man, Steve Jobs.

Water Isaacson’s biographical book, Steve Jobs, paints a picture of Mr. Jobs that is both fascinating was well as cautionary. By having unprecedented access to the very private world of Steve Jobs for over two years, we are given a portrait of both the technical and artistic genius that many have applauded, but also the deeply flawed, insensitive, bully of a human being that he often was. No punches have been pulled. As the author noted:

“He had never, in two years, asked anything about what I was putting in the book or what conclusions I had drawn. But now he looked at me and said, ‘I know there will be a lot in your book I won’t like.’ It was more a question than a statement, and when he stared at me for a response, I nodded, smiled, and said I was sure that would be true. ‘That’s good,’ he said. ‘Then it won’t seem like an in-house book. I won’t read it for a while, because I don’t want to get mad. Maybe I will read it in a year—if I’m still around.’”

There is no doubt that Steve Jobs was an extraordinary individual. From a distance, through the adoration of his fans and the Apple mystique, it is quite possible to be affected by what some of his coworkers have labeled the “Reality Distortion Field”, a state of viewing and believing something that isn’t real, or least not completely accurate. Jobs’ reality distortion field led him to assume the attitude of always being right and others who disagreed with him of always being wrong. This had mixed results in his career and personal life. He hit some major homeruns with some of his products. Yet, he also fielded some major duds, and nearly lost his entire fortune when he was unfettered and free from the constraining input of others’ more balanced arguments.

Starting life as an adopted child in a loving and nurturing home, being ingrained by his father with a love for electronics, mechanics, and especially with a sense of craftsmanship, he grew up with a firm belief that he was special and usual norms and rules did not apply to him. He was, he thought, destined to be a prince. Even as an adult, he ignored the handicapped parking signs and parked there anyway in his Mercedes that never bore a license plate.

In summary, Jobs grew up in middle class Palo Alto, California. In high school he earned the reputation of prankster and geek. As a college dropout, he took LSD, traveled to India to experience the gurus and Eastern philosophies. He lived on a commune in Oregon. He worked for Atari. With his friend and partner Steve Wozniak he built the first Apple computer and made $100 million before he turned 25. In a power struggle in 1985 he lost control of Apple and was ousted. His second computer company, NeXT, was a failure and hemorrhaged money. He then purchased Pixar for a tiny amount from George Lucas, who had pressing cash needs, and with director John Lasseter, turned it into a wildly successful animation studio. He then returned to Apple and assumed control. Soon he saw the Internet as a way to build an integrated consumer electronics company. Computers would become the hub of one’s digital life, and a succession of revolutionary new devices, the iPod, the iPhone, and the iPad, would be the spokes.

This is the story that makes the skeleton of the book. The meat and the fat are far more interesting.

As a boy, Jobs rejected his parents’ Christianity because of his reaction to the starvation of children in Biafra, and his disbelief that a loving God would allow something like that to happen. In spite of his parents’ attempts to explain, Jobs begins to assert his typological attitude of “I’m right and everyone else is wrong”, even if the “everyone else” included God. This attitude is even manifested in his belief that he didn’t exude any body odor, and the requirement of regular bathing that everyone else had to endure was not one with which he needed to indulge.

At Apple, Jobs was known to berate, belittle, and scream at those who either disagreed with him or produced work he felt was not up to his sense of what it meant to be an “A-List” player. He could fire an employee on the spot, and sometimes cry when he did not get his way. To be fair he also cried when speaking of loyal friends and employees and good experiences with his family, so he wasn’t merely a cry-baby. Mixed in with the cold, callused, methodical corporate leader was a sentimental and sensitive soul, but only when focused on such things. Jobs’ attention and emotional ray gun swept around like a lighthouse. One minute it was on you, warm and enjoyable, the next, pointing in another direction, it could be cold and detached.

His life was played out in three major acts. Act One begins with his birth, abandonment, adoption, development and creation of Apple Computers. Becoming a multimillionaire so young in life made him even more self-assured and ego-centric. Act Two starts with his ouster from Apple and his fall into near desperation as most of his money is lost in the debacle of NeXT. There is a tempering and a mellowing, perhaps a maturing. Perhaps not. Maybe he merely learns better way of controlling those around him without the adolescent fireworks. Maybe not. Finally, Act Three begins with his return to a demoralized and disorganized Apple, and ends, of course with his death, but not before major successes and industry transformations are brought about because of his incessant insistence on quality, innovation, and complete control of the users’ experience.

Isaacson writes:

"The saga of Steve Jobs is the Silicon Valley creation myth writ large: launching a startup in his parents' garage and building it into the world's most valuable company. He didn't invent many things outright, but he was a master at putting together ideas, art, and technology in ways that invented the future. He designed the Mac after appreciating the power of graphical interfaces in a way that Xerox was unable to do, and he created the iPod after grasping the joy of having a thousand songs in your pocket in a way that Sony, which had all the assets and heritage, could never accomplish. Some leaders push innovations by being good at the big picture. Others do so by mastering details. Jobs did both, relentlessly."

This is a wonderful book, well worth your time, thoroughly enjoyable, and eminently readable: a balanced telling of an unbalanced life.

It has been noted elsewhere that there are many parallels between writing software and building homes. The most obvious aspect is that in each case a thorough well-planned design is crucial to the success of the project. At dX Software Systems we recognize the importance of good system design, and we attempt to educate our clients to do the same.

But imagine if an architect had to work from a specification like this!

Dear Mr. Architect:

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion.
My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (for example, the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)

Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.

To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.

Please don't bother me with small details right now. Your job is to develop the overall plans for the house, i.e., get the big picture. For example, at this time it is not appropriate to be choosing the color of the carpet. However, keep in mind that my wife prefers blue.

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. Therefore, it should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features of this house.
I advise you to take a look at my neighbor's house which he constructed last year. We like it a great deal. It has many features that we would also like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that cannot happen very often. Contact me as soon as possible with your complete ideas and plans.

P.S. My wife has just told me that she disagrees with many of the instructions I have provided in this letter. As architect, it is your responsibility to resolve these differences. (I have tried in the past and have been unable to accomplish this myself.) If you cannot handle this responsibility, I will have to find another architect.

P.P.S. Perhaps what I need is not a house at all, but rather a travel trailer. Please advise me as soon as possible if this is the case.

This little story has been floating around the Internet for years, and we take no credit for its origin. We have posted it here merely to humorously illustrate a common problem that all software developers encounter. A client who is not settled in his expectations of the finished product, and a project that is not scoped out entirely will only lead to frustration and ill-feelings.  Nobody wants a business relationship that turns into something you only want to avoid.  

Sometimes, even when well informed on the project, we come up short trying to wear "all the hats", and have a tendency to sit too close to the problem to see the solution. Understanding the ways in which a consultant can be a resource to overcome these pitfalls allows us to fully utilize time management potential and get back in the driver's seat.

WHAT IS A CONSULTANT?

A consultant is not a temporary or part-time employee. A consultant is an independent contractor offering his or her specialized services or skills to clients for a fee. Like your doctor, lawyer or plumber, he is a counselor who is employed for his or her knowledge, experience and judgment as well as his skills. Besides being an authority in a specialized field, the consultant is project or task oriented. He can see the solution for the problems without the tangle of conflicts, daily crises and problems that typically interrupt an executive.

WHAT DOES A CONSULTANT DO?

Being experts in their fields, consultants are highly trained in analyzing problems and developing solutions that satisfy management objectives. Often, they are asked to implement these solutions. Being free of time-consuming daily operational duties, they can direct their attention to the project. A satisfactory result is reached more quickly and objectively. This enhanced productivity makes a consultant a real bargain. Projects or problems that hang on and on while waiting for attention often have direct and hidden costs beyond realization.
Focusing their work according to the client's objectives and centering on results is an important measure of the consultant's contribution. Often, the accomplishment of the goal can be measured in dollars, time or quality. Comparing this with the time needed by an employee for training and fulfillment of the end is one measure of value. Another is the quality of the solution or attainment of the objective. Often a low quality solution is worse than the problem and leaves a haunting effect. Sometimes, the problem is like a hole in a boat, it gets harder and harder to save the ship, the longer the problem exists.

The consultant performs tasks such as:

• • Situation Analysis 
• • Research 
• • Planning 
• • Evaluation 
• • Problem definition 
• • Idea Generation 
• • Implementation 
• • Design 
• • Selection 
• • Testing 
• • Training 
• • Reporting

WHEN TO USE CONSULTANTS

Consultants may represent the most cost-effective solution under many conditions. You should consider using them when you need:

UNIQUE SKILLS -- When specialized experience and knowledge are not available within your firm consultants are the answer.

ONE TIME and OVERLOAD HELP -- Using Consultants for peak-period or unique projects can help equalize the workload of your permanent staff.

INNOVATION -- Consultants contribute fresh thinking and are very effective as catalysts for alteration and change.

TRAINING -- At all levels in the company, Consultants can provide training. Formal seminars as well as one-on-one training sessions will benefit your company.

TEMPORARY HELP -- During peak periods can be useful. When near-term business situations are uncertain, consultants can perform the work without long-term commitments.

GETTING THE MOST FROM CONSULTANTS

Having selected a consultant, to insure maximum effectiveness follow the next few suggestions:

EARLY INTRODUCTION -- Bring the consultant into the project early. Consultants can often guide initial decisions or suggest immediate solutions.

DEFINE THE TASK -- Good definition speeds problem solving and saves consulting time. All data bearing on the assignment should be provided at the beginning and as needed during the term of the project.

PROVIDE NECESSARY SUPPORT -- The consultant should be introduced to the relevant systems and personnel as soon as possible.

MONITOR PROGRESS -- The consultant should keep you informed as to progress.

VERIFY RESULTS -- Decisions should be made regarding conclusions, advice and implementation.
Consultants can provide the missing link between your company's present problems and future goals. They are most cost effective when you make the effort to use their skills to best advantage.

Often, folks who are looking to have computer programming done are surprised when the consultant presents them with the estimated cost of a project. Their objection usually takes the form similar to, “Why is it so expensive to contract with a software developer?” or “I can hire a junior programmer for a year for what you want for this!” These questions really are misunderstandings of the value an experienced consultant brings to a project.

If a contractor quotes you a rate of $100 an hour, you’re probably going to be quick to respond with, “That's about $200k a year! Forget that!” But that misses a lot of things. Aside from the fact that the contractor has to pay their own insurance, workers comp, FICA, and all the overhead of running a business, let’s focus on what you're actually getting.

It’s not merely an hour of that person's time you’re getting. You're also getting the years of experience they have in doing similar challenging work for other firms. They've seen far more problems and disastrous projects than a junior programmer will see in even their first two years. You're getting access to a portfolio, a code library and methodology, they have developed over the years that they can draw from that is largely tested and true. You're buying the experience of all the late nights that they spent on past projects, pulling out their hair, finding solutions to knotty problems, so that pitfalls are quickly avoided on your project. Essentially, you're paying for a much better ability to control the cost and schedule of your project.

If you’re still thinking, “It still seems expensive”, well, face it, you can't sell an hour more than once, and you’re the sole customer on this project. This is simply the nature of custom software. Microsoft can sell Office for a couple of hundred dollars a copy, even though it may have cost them millions of dollars to create, because tens of millions of copies will be sold. A contractor selling you a finished product will sell it to you at a lower cost per hour basis, because you're sharing the development hours with all of the other people who have purchased the product.

Does it always make sense to contract with an independent developer? Of course not, but the next time your project has zoomed past a deadline or gone over budget, think about the depth of experience you have working on it, then ask yourself, “Is having this project where the project schedule calendar says it should be worth the cost of a consultant?”