3 ms·
Hardware engineers have more clearly defined requirements, It's also well understood by everyone that you can't just change the design halfway through productio
by gnarbarian 13y ago
Hardware engineers have more clearly defined requirements, It's also well understood by everyone that you can't just change the design halfway through production with no additional cost. Hardware engineers clients are mostly other engineers who know their shit very well. Hardware engineering is also more formalized with a larger percentage of engineers actually possessing relevant degrees with common well established means of communicating and thoroughly clear phases of development for a project.
People hiring consultants to build them software are generally non-technical. On most projects the following problems may occur:
Problems With Clients:
1) They don't konw what they really want.
2) They are bad at communicating what they really want.
3) Not enough people from the organization are brought in to weigh in on their needs / actual duties.
4) Too many people are brought in, many with conflicting interests. (bike shedding). [1]
5) Critical omissions are made regarding idiosyncrasies of their infrastructure that are never brought to light until far too late in the project.
6) people trying to change the direction of a project late into development
7) complicated/redundant policies or procedures which are incompatible or inefficient to implement using the tools the client requires you to implement them in.
Problems with Consultants / Contractors:
1) Over confident estimates
2) They are bad at estimations / unfamiliar with the tools required to do the job
3) They are bad at communication / rooting out the the real problem early
4) Unable to detect confusion/bullshitting from a client or are unwilling to investigate it.
5) PMs who make promises they are unable to keep
6) PMs who do not understand the details and make decisions without consulting those who do
7) Developers who avoid asking the client for clarification
8) spineless developers/PMs who screw themselves to avoid confrontation
9) Procrastination
[1] http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
- ohyes 13y ago8 and 3 are the biggest in my opinion. 3 should have it added that the we are bad at getting the requirements out of customers, then writing it down and sticking to what is written. 8 isn't just about confrontation, the person who says 'yes' is more likely to not be fired than the person who says no. You need to frame all of those times you say no as alternatives, not as flat saying no.
- hackula1 13y ago> the person who says 'yes' is more likely to not be fired than the person who says no Within reason, I completely disagree with this. The best engineers and PMs are the ones who effectively manage expectations.