Happily looking stupid

Being able to look stupid has many advantages in project management

I’ve recently been thinking about one of my biggest strengths: willingness to look stupid in front of people. I think I first realized this power when I first started to play the harmonica with local bands at bars (some of which were actually ok as long as I was outside the bar)…

Being comfortable with looking stupid has allowed me to:

• Ask the stupid question that everyone think everyone else knows, but no one really does
• Question why the go-live dates are being pulled in, when all indications show that the project delivery dates should be moved out
• Ask a top developer why the suggested confusing/mind-boggling approach is the best
• Not show up for mandatory meetings, when the meeting agenda is about setting up other meetings or when no agenda is present
• Not stay late when there’s no other reason than to look good in front of the boss
• Ask HR why such wonderful company policy about safe/happy work environments and balanced work/family time is never really inforced
• Question why cost cutting is the focus instead of opportunity taking
• Keep trying to promote change based on issues and not symptoms
• Ask why exceptions that happen all of the time are considered exceptions

Looking stupid has not always been easy, but as time goes on and I feel more confident in myself the more looking stupid seems to be the right thing to do

change to IT Project Guide - Open Source look/feel

I haven't really updated the IT Project Guide - Risk Management project in a while (outside of some reported bugs) - thinking about moving to a new look: http://sourceforge.net/projects/itpgrm/

compare to what it is now:

http://itprojectguide.org/PMBase/risk/home

??any thoughts?

process corrupts, absolute process corrupts absolutely

Why are there continued changes in IT project management and SDLC processes? And why can’t developers and project managers define a single process that both agree on? Are there that many conflicting goals that prevent this from occurring? I think the root cause is the idea that a single process can be defined and put into place today, based on yesterdays findings and that will be beneficial tomorrow. No plan to put a stagnant process in place will never work, problems change, environments change and most importantly people change.

I think this is the root cause for continued process change, for example KanBan, which is based on Toyota’s car manufacturing process, just as Six Sigma was developed by a Motorola process break through. If you look closely enough, new processes are old processes re-purposed, re-named or slightly re-factored…why? I think the reason is that, once a process is put in place it goes through a phase of being formalized, dumb’ed down so everyone can follow, forced on to every new project and (most unfortunately) used to measure people’s ability and commitment to the company….exactness to steps instead of intent is followed. As the process becomes more out of step with current needs of both projects and people, they are targeted as being old and wrong and new ones are ‘discovered’ and implemented.

We need to get everyone (aka management) in line with continued process improvement (or whatever the new term for that is) and ensure that a meta-process is in place to continually review and improve and replace as needed.

KanBan - http://agile.dzone.com/news/introducing-kanban-flow-and

(image via: http://timmonsgalleries.com/FA-rep.html)

Netflix Culture Presentation

Great presentation with a lot of great ideas!

Culture

View more presentations from reed2001.

How we learn - reading other people's discussions

I've been following a great discussion on KanBan at: http://tech.groups.yahoo.com/group/extremeprogramming/

you have some VERY INTERESTING people involved including Ron Jefferies and Kent Beck...I would highly recommend any interested in hearing some top authorities discuss an important item (project approach) to join and listen in.

Front loading success

In a recent article, Tom DeMarco stated that Software Engineering is an idea whose time has come and gone, basically stated that heavy management /oversight is mostly needed for projects that have minimal benefit and those projects with the most to offer require less…and that the real effort should be focused on ensuring the right projects are selected and then on anything that will help those projects have the highest probability of success.
If that’s true, than we need to ensure that we focus on ensuring that all processes in place allow for the least friction to the project team while ensuring focus is on front-loading success factors into all projects: from selection of the project, team selection and management selection. Just as QA’s real benefit is ensuring quality processes are in place, from requirements writing to delivery, a project manager’s real benefit to an organization is in ensuring the right project is selected and that it is given the proper start in life to succeed…unfortunately most PM’s are still looked to for delivering daily project updates and bad news about slipped dates. (just like QA is looked to performing post code complete testing)…
No matter which project management process or SDLC is selected, no matter what quality team is used or outstanding platform – a ill conceived project will fail and potentially cause collateral damage to the business.
We, PM’s, need to remain open minded to new ideas and be brave enough to speak out when needed.

Tom DeMarco Article: http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

(image from www.ac-orleans-tours.fr/.../insurgent3.htm)