Friday, April 09, 2010

Lessons Learned The Hard Way

I began a pretty interesting exercise during my time spent waiting for the morning train this week - it's amazing what your brain comes up with at 5 a.m. I began to make a list of lessons learned from project failures, focusing strictly on those project failures I've personally experienced. Dug up some really painful memories but gathered some really choice nuggets of wisdom. Thought I'd share a few and see what ya'all think.

One caveat: these points may seem a little on the dark or cynical side, but keep in mind that these lesson were learned through failure. That makes them lessons learned the hard way. Rest assured that I genuinely love what I do.

Now let's hit the list:

- A project delivering phenomenally-coded apps is still a failure if the users are not happy with the delivery.
- If your project sponsor won't back your project team when the pressure is on, prepare to observe the dirtiest side of a bus.
- Saying "no" to a sponsor, customer, or stakeholder is always a bad thing. Present the trade-offs and let the big dogs make the choices.
- Users always want to see a mock-up the minute you announce you'll be building a mockup.
- Multiply your development estimates by 3 and add 20% before you tell anyone how long you think it will take. It's never as simple as it looks at first.
- Users can never list and clearly describe all their requirements; do your best to gather requirements, do it quickly, build UI prototypes based on what you know, then show those prototypes to your users and be ready to take lots of notes.
- It's tougher to obtain true success with packaged apps than it is with custom development but, in either case, it's darn hard.
- Usability really, really matters - design with that in mind.
- If you work in the software business for any significant length of time, you'll experience your share of failures; learn from the experience and move on.
- It's all personal, regardless of what gets said.
- Being correct on technical issues does not mean you're right.
- Always have another set of eyes review your work.
- We're all selling all the time...it's just that some of us don't know it.
- Tighter teams deliver better products.
- Work can be stressful and fun at the same time.
- Be quick, but don't hurry - John Wooden; the idea is that hurried work tends to be sloppy work - follow the processes you know will work, but don't let process control stymie results.
- Tech is a means, not an end...the technically simple solutions are often the best solutions.
- Acceptance happens incrementally and is best started with the lowest layer of management.
- Flexibility and resilience are traits worth their weight in gold.
- The only thing worse than unemployment is to work and not get paid in some way for it.
- Schedule may matter most, but you can learn a lot by following the money.
- Love the work or find another gig - life is too short is labor away in self-imposed misery.

Long list, but I think it's a good one. Got anything to add to the list? Comments welcome!



- Posted using BlogPress from my iPhone

4 comments:

Anonymous said...

Sounds like you had the same week I had. Many of the 'lessons learned' were one that came up in our under-staffed, over-promised IT organization. Us that have been in IT many years know have experienced, learned and lived these but we keep having to re-do them with every 'I know everything' attitude new user/manager/rising star that comes along. If they would just listen to us a little some of the time ....

blog said...

all are true. thx for the list. I would like to add the followings:
1- a good manager with modeicore team perform better than excellent team with medicore team
2- proactivity saves all disasters

justadba said...

Floyd,

The best comment you listed was:

- It's all personal, regardless of what gets said.

There is nothing that beats that comment....:-)

Good post.

Hobie Swan said...

I'd like to comment on two of your assertions: "A project delivering phenomenally-coded apps is still a failure if the users are not happy with the delivery. And "Users can never list and clearly describe all their requirements..."

I'd likeo propose a methodology called "mind mapping" as a way to address both of these situations. When you sit down with a client, project a mind map on the wall, and work together to populate the map with key requirements, you might discover 2 things:

1. The app you deliver will make the client happy because you've spent time with the client to make sure you understood their pain points.

2. Given a supportive environment, backed by thkind of transparent note-taking mind mapping engenders, clients can do a very good job of listing and explaining their key requirements.

If you'd like a small sample of how mind mapping can improve vendor/client relationships and lead to better projects, please visit http://mapthink.blogspot.com/2010/04/using-conceptdraw-mindmap-to-gather_19.html.

Let me now if you are interested in taking ConceptDraw for a test run.