Hi there! Welcome to our blog. Don't forget to sign up for our free RSS feed. We Triple Dog Dare Ya! And thanks for visiting!

We’ve been involved with a lot of projects here at Triple Dog Dare Media in the past 4.5 years. They’ve ranged from fixing someone’s battered PayPal script (1.25 hours) to building an enterprise-level CMS for a Fortune 1000 client (8 months) and lots of stuff in between.

We’ve worked for clients that are amazingly communicative, transparent really, and others that were like brick walls (and even one or two we had to fire because we weren’t really quite sure if what they were doing was exactly legal). We’ve worked in the non-profit and government sectors, and industries as far-flung as manufacturing, consulting, travel, sales, software publishing, and contracting services.

One of our first clients, Dave Claunch of Liaison Resources, is one of our heroes. He taught us a lot about contracts, creating deliverables that everyone could live with, and the details of negotiation. Sitting at the table with him was like getting your butt beat by a real poker pro in Vegas–you didn’t mind the beatings because you were learning so much.

Others, like Mary McCommon of IBM and Renee Delaune of Delaune & Associates also come to mind as people we’ve learned a lot from. These two ladies have moxie, business savvy, and lots of years on the mean streets of Corporate America. Without their guidance we’d never have made it out of toddlerhood as a company.

We won’t take the time to mention the bad stuff specifically–and no, just because we haven’t mentioned you with the good, it doesn’t mean you were an example of bad stuff!–but I thought it might be helpful to go over some of the ways a project can fail. I even asked my staff to help me compile the list.

And yes, each of these are for real–they’ve actually happened to us on real projects. Not all of them caused total project failure, but they certainly contributed to more than anyone’s fair share of trouble.

So here goes….

• Don’t divulge budgets, deadlines, or complete names of stakeholders–or keep changing this information without telling us.
• Set a deadline of “whenever”.
• Set a deadline that is ridiculously close and arbitrary (i.e., build an extranet portal in time for a sales meeting in 10 days).
• Tell us we don’t have time to fully flesh out functional/technical requirements, but do complain when applications aren’t built the way you wanted them.
• Neglect to tell us if certain minor stakeholders (like the CEO’s spouse) have veto authority on some aspect of the project.
• Opt for the all-or-nothing moonshot instead of smaller, less-risky, phased deliverables.
• Remove QA, usability testing, and documentation line items from the budget.
• Communicate with us piecemeal (hundreds of little emails, IM notes, hallway conversations) and never in structured meetings or with lists/agendas.
• Avoid user testing, even with proxy users from your own company before releasing software to the target market.
• Insist that prototype only be viewed/tested by executive committee and not the actual users of the product.
• Insist on cutting project management from our side because you have a project manager from marketing assigned on your side.
• Insist on not using a version control system and backups for the project.
• Insist on announcing to the entire marketplace what your intentions are for the project even before we’ve had a kick-off meeting.
• Set a kick-off meeting but don’t invite key stakeholders.

Bookmark:

Tags: No Comments