Hourly Consulting Rates for Embedded Work?

Pardon my interjections but I have some experience with this subject.

Management often makes decisions to cut test and debugging time. Management often allows feature creep with no corresponding change in schedule. Management is responsible to have in place a quality system designed to properly validate the software. Management often makes decisions that force software engineers to take shortcuts or work under duress. Management often doesn't know enough about WHAT they are managing to put in place things like version control, peer review, other design controls. They don't enforce unit and integration testing; things which many programmers won't do if they can get away with it.

Sofware failure and development failure are not the same thing, but thay are indeed both management failures. Here is a great essay on development failures:

Ouch. No, I didn't mean "management" in the business sense. I meant "management" in the sense that how can I (a guy how has to deal with real management) really make sure my team is doing the best job they can.

You are absolutely correct. In my environment, deadlines and quality can be mutually exclusive.

I'd like to figure out a way to help my team strike a balance between management demands and their desire to do the job properly. Sometimes this is a top down thing. I believe this can also become a bottom up thing.

-Rich

If you were in Silicon Valley, at least $60/hour is a competitive rate to charge. (It isn't 1999-2000, where you can charge double). I moved back to Chicago after the recent tech meltdown. In the Midwest, a consulting company can snag a $60-$70/hour contract, and give half to their engineer who works the contract. A parttime freelancer can competitively bid at $50/hour.

I am currently using my laptop as the main network connection. The other systems are being re-configured once I have moved the important data off. I know that most of my mis-spellings are due to me typing too fast and a slight lack of re-reading before sending. I will try and slow down a bit.

The failure of management occurs in several facets.

Inappropriate organisational structure - such structures owe more to office politics than the technical needs of managing projects. This often leads to poor decision making.

Over commitment by management - the timescale problem where impossibly short timelines are assigned by the management for project phases. To solve this project management need to, on occasion, say that it cannot be done is so short a time. This aspect is exacerbated if leading edge technology is being introduced without adequate pre-testing.

Destruction of Team Spirit - Some management cultures tend to be very soul destroying and leads to high staff turnover.

Lack of importance attached to training - not ensuring that the workforce is adequately trained and motivated. This training is not only to be in the required skills but also in the process and procedures employed by the company. Is your company part of the Investors In People initiative. The above are just a few of the things that can become Critical Failure Factors. I recommend anyone at any level of project management to read Stephen Flowers book "Software Failure: Management Failure" published by John Wiley & Sons ISBN 0-471-95113-7. There are some quite telling project failures examined for the root cause of the failure.

I am not guaranteeing that you can correct your own management structures and attitudes just by reading the book and implementing changes that address the problems so highlighted. However, you can improve the situation you are in by at least thinking a little more about how you approach the project management task.

If your organisational structure can be adapted to do so, I would reccommend employing a slightly bombastic personality in the role of Document Registrar and make him fully responsible for the issue of all documentation into and out of the development organisation.

Hope that helps.

Guy Macon wrote in news:8MOdncNoXPK snipped-for-privacy@speakeasy.net:

Following on from the excellent Trance document on Guy's site, there is another "corporate culture" factor that I believe leads to project overruns, that is the "work all hours" drive.

I have observed that in countries that have substantially more paid vacation time than America, the work time tends to be more focussed, and there are fewer water fountain social meetings. It is unrealistic to expect people to work their hardest without adequate time to recuperate on a regular basis - a week every ten to twelve weeks or so rather than one vacation a year. Of course, not everyone actually *takes* all their vacation time, but they have the opportunity to take a timeout rather than burnout.

Emergency 12+ hour days and/or seven days per week working are sometimes necessary, although they should be regarded as a symptom of things going very, very wrong with the management (expectations) of the project, rather than standard practice. Again however, this is effective only in the very short term - after ten days there will be NO benefits from pushing the developers so hard. The only thing you can be sure of from this practice is that sooner rather than later you will lose key people from your team.

Peter.

I bill between $85..$100 USD per hour plus expenses. ( travelling, car, plane, hotel etc.. )

never had any complaints yet. thinking of increasing to $90..$120 if you need a professional then you have to pay professional prices..

think what an employer will pay ? on W2 with SS, overhead, medical etc.. i'll bet they pay $120+ an hour for an engineer and still don't get the quality because that type of "job security" breeds contempt and laziness.. just look at the public sector.. imagine how efficient it would be if run by contract staff..? :)

A grease monkey/AC tech/plumber/electrician will charge this rate.. when was the last time you paid a lawyer $35 and hour....? don't make yourself and the profession cheap.. get what you know you are worth..

ok, i'll stop ranting..

I cannot type on a notebook. I cannot type on a regular keyboard either except that with 20 years experience, somehow my fingers do better than two finger'd typing. I just can't look at what my fingers are doing without them failing. ;-) I assure you that I wasn't judging the content on the spelling.

I'm glad you said often. I would have assumed always.

Where I am, Marketing always get's the blame for the schedule. I don't think management should be able to use this excuse, however.

I think the simple fact that unresonable schedules are set can detroy team moral. It's almost as if the team is being set up to fail.

I agree. People are important. Retaining people is important. Skilled people are very important. How can one convince management that an unrealistic deadline cannot be met simply by increasing the resource count? We (my team/my company) need to build a good, qualified resource base. You can't (normally) just bring a guy off the street (or another department) and expect him/her to immediately reduce the deadline by however number of manweeks the additional head indicates in the spreadsheet.

I'll check this out.

Absolutely agree.

-Rich

Thanks Guy.

-Rich

... snip ...

In fact you should expect him/her to immediately *add* some number of manweeks to the project, required for training and integration.

IMO, the best for all parties is job pricing, not hourly pricing. You may use an hourly rate to help calculate the cost, but fixed price for a defined goal is the way to go.

A necessary prerequisite for fixed price is very well defined requirements. A good side-effect, imo.

Good grief, no. What we need are results. Certification doesn't guarantee results.

Of course there's no guarantee, but it seems to work fairly well for most professions. By the way, how do you feel about unregistered civil engineers, doctors, lawyers, auto mechanics, carpenters and hairdressers?

-- Joe Legris

Civil engineers - many civil engineering designs are done by unregistered (non-PE) people who work for a PE. The PE may do nothing but paperwork and presentations.

Doctors, lawyers - Keep in mind that practically all the doctors and lawyers who are disciplined, booted out, or sued for malpractice are registered :-) OTOH, there have been quite a few cases of doctors who have successfully run a practice for years, healing innumerable people, and building a wonderful reputation in their community, only to be exposed as unlicensed. I dunno about lawyers, except that despite strenuous effort here in Arizona, they have been unable to put the paralegals out of business.

Auto mechanics, carpenters, hairdressers - Actually, I know nothing about hairdressers, except that my aunt used to do it part time, and had no license. Auto mechanics and carpenters don't have to be licensed, anywhere I've lived, and I've learned from experience that the "certification" hanging on the wall of auto repair shops don't guarantee good work, only higher rates.

None of this necessarily has anything to do with programming, of course. Programmers aren't a "Profession" in any case - just ask the nearest doctor or lawyer.

Excellent point.

In my opinion, you have correctly identified the problem but missed the mark in identifying the cause. Tom DeMarco's Trance State Conjecture seems to better explain why everyone rolls their eyes when software folks produce time and cost estimates. See

That has indeed been said, but it isn't true.