This is Mike Cottmeyer's Typepad Profile.
Join Typepad and start following Mike Cottmeyer's activity
Join Now!
Already a member? Sign In
Mike Cottmeyer
Recent Activity
Glen... just catching up on my blog reading from being away a few weeks. When I have 200 posts to catch up on... most get skimmed. I find that I read yours end to end. Thanks. In certain applications I agree that we need analyze and learn from our mistakes so we don't repeat them in the future. As I was reading your post here... I kept asking myself why we don't do this. Could it be that the barrier to entry to building planes and bridges is so high that we can slow things down sufficiently to put in place these kinds of controls? The barrier to entry in software is much, much lower. Someone in the market will drop the controls... and if they have good enough talent... create a decent product, much faster... and each your lunch while you are doing your postmortem? Thoughts?
1 reply
There is tremendous pressure to cut estimates in IT organizations. This goes for those organizations that sell products and services externally as well as internally. Most project managers do not carry enough organizational weight to say 'no'... and saying 'no' makes you very unpopular with many execs... even if you provide credible alternatives.
1 reply
Hey Jurgen, I think and write a lot on this, but more from an Agile/PMI perspective. One of the things I like to focus on is the cost of change. Traditional PM is supposed to be deliverables based (not activity based) and open to change. The problem is that the cost of change is much higher in traditional methods... thus leading to resistance to change... thus leading to inflexibility.
1 reply
Once again... nice post. I think the answer to your question is yes. But... here is my take. It all has to do with the level of uncertainty and your ability to live with the COST of all that documentation and overhead. Some agile principles can be applied to any problem domain and I think that most problem domains would benefit from many of the practices. The hard core agile stuff (the magic beans) is really optimal when you have to get something to market fast... faster than your competition... and with high quality... and when that speed and quality is more important than specifically WHAT gets delivered to market. That is not the case when building flight control software or software that runs life support systems. It is the case when adding features to Google search or Google mail or VersionOne Enterprise or Evernote or any number of other products that have to be first with new an innovative features. Some teams using just don't need the level of rigor that is contained in the DOD standards. That said, many teams adopting agile think they can't write ANYTHING down, that they can't have any governance, that they can do any risk management... and to me, that is just crazy. Agile gives teams a lightweight way of being disciplined and predictable. Just enough process to keep us on the edge of chaos without going over ;-) If those heavy standards are required for your problem domain, and your customers are willing to pay that price, and your market is willing to wait for your product the time it takes to create all that stuff... do it. If not, and you can deliver reliably without out it, you have to really evaluate if the cost of process is worth it. What value is it providing? I usually find the answer is somewhere in between. I have yet to work with a client could get a way with the basic bare bones agile approach. Thanks again for your efforts here.
1 reply
I would make the case that agile projects don't deliver earlier than planned, they plan to deliver earlier ;-)
Toggle Commented Feb 13, 2009 on Make Speed Not Haste at Herding Cats
1 reply
Oh... and one more thing... some where I missed the post where you explain what the "magic beans" approach actually is. Sometimes I think you are talking about agile... sometimes just bad agile... but I am never really 100% sure. Can you help me out here?
Toggle Commented Jan 23, 2009 on Waterfall? Not Allowed! at Herding Cats
1 reply
Glen... I think that Jason has it right here. Waterfall (the red herring version) does exist in a lot of places. Unfortunately so does the mindset that documentation about a deliverable = the deliverable or even value to a project. If the community could understand PM as well as you do, and understand what done looks like, and could measure physical % complete... we would be in much better shape in the software industry. There are some agilists out there that have taken their reaction to bad project management too far... to plan nothing, measure nothing... a no accountability model. As always, the truth lies in the middle. A well disciplined agile project that tracks physical % complete against software product features starts looking a lot like what you are advocating. Agile is not for every problem, every domain. There are A LOT of us that are out there operating in environments where the cost of DOD standards is just too high. We need structure and predictability, but not that level of rigor. As always... I appreciate your contribution and your insights on project management. I have built many of your ideas into my presentations.
Toggle Commented Jan 23, 2009 on Waterfall? Not Allowed! at Herding Cats
1 reply
Hey Glen, I appreciate that you attended my talk. It means a lot to me that you'd take time out to hear me, and even more that you gave me some press in your blog. These talks are always hard because you only have such a short time to get across such a broad topic. This talk started as a 90 minute preso at the SQE conference in Orlando and our marketing team asked me to take it down to 40 for the webinar... I wish I had the extra 50 minutes or had spent more time refactoring the content to tell a better story in 40. That said... I totally agree that I over simplified some things. I do that intentionally. The reason is that so many software project managers (my particular problem domain) just don't get it. It is not the complexities of earned value they don't understand (though they probably don't), it is equating the delivery of an intermediate artifact to the delivery of value. Work applied seems to equal value earned. I have been getting strong reaction to several of my latest posts (this talk, one on dependencies, etc.) because my statements are so bold and absolute. My goal is to break down the fundamental flaw in the prevailing software project management paradigm and challenge these ideas at their core. So while I make a comment like 'break dependencies at all costs'... clearly there are dependencies that have to be managed. The problem is that most folks think they have to create extra dependencies that don't need to exist, treat them like gospel, and manage the hell out of them... to the point the team struggles to release software or delivery any incremental value at all. By simplifying the argument to something so bold as 'break them all', it flips thinking toward a mode of question everything, validate all assumptions, and manage the hell out of what is left. So many project managers I work with have no meaningful project controls in place. It becomes a cult of personality where all decisions get made through them. Over simplification... yes, did 90% of the PMs on the call take something from the comment... I think they did. If a task is nested under a discrete deliverable that adds value, by all means, put them in the plan. I consistently work with project managers that have nothing but tasks in the plan and are tracking earned value, when in reality no value is EVER earned. I have run teams that do weekly meetings, some that do daily... I have also worked with teams that don't talk to each other at all. Oh.. I guess I should mention that this 'crapola' I am talking about is the first stuff I look for when I am picking up a troubled software project. I try not to let this exist in projects I get to run from scratch ;-) And... I see this stuff on a lot of teams I consult with. So... thanks for the space to rant. I suspect there is more bad project management out there than we are all willing to admit. There are some that take practices and force fit them into flawed organizational cultures. Some are just blatantly misapplied. My goal is to break down these flawed underlying assumptions, and I am known to use some oversimplification along the way. http://www.leadingagile.com/2008/12/so-who-reads-leading-agile-anyway.html As always... I enjoy your work. Looking forward to your next post! Mike
1 reply