Taking the "pulse" of a project

By -
Every PM/PjM's daily worry: How do you know how your team is doing?   How do you identify what is working well vs. what needs fixing before it becomes a serious issue and kills your timeline?  How do you take the temperature/check the pulse of your product in a way that helps instead of adds overhead?  How do you stop frustration before your team gets bogged down and productivity tanks?

Which got me thinking: What would be the minimal amount of information (lowest process overhead) you need from your team to take the pulse of the project?  Potential answer that I'd love to impose on my next team as a COB daily form, with some sort of automated system that harasses anyone that forgets to fill in the form before they sign out for the day (and allows you to fill out the info via a mobile web interface during your commute home):
  1. Locate today on a X/Y graph: 
  • X=How intense was today? (not at all to crazy intense)
  • Y=How frustrating was today? (not at all to very frustrating)
And if you are not near the center of the graph, fill out:
  • What went right and what went wrong today? (a few words required if you had a wild day)
And, you always can fill out:
  • Any potential looming issues in the next 2 weeks or ideas for improvement? (unlimited, optional)
I believe that the two axis of "intense" and "frustrating" are orthogonal enough to cover correctly gauge the team's attitude and be able to predict impending problems and areas where the team is flailing.  A project can be super-intense and not at all frustrating (ideal), non-intense and non-frustrating (floating), intense and frustrating (going to miss the goal) and non-intense and frustrating (misdirected management).  Because looming issues or ideas is optional, the average input would fit in the 140 twitter chars, but you'd likely want to keep this data internal.  This would only work if the entire company participated, this is NOT  for engineers only.

Imagine your sales team sharing on a daily basis their intensity/frustration levels in a way that was visible to the engineering team and vice-versa, encouraging sharing of ideas and potential landlines in a way that becomes natural and expected?  "Ideas for improvement" is intentionally vague: It intentionally doesn't specify if it is a product improvement, a process improvement, a personnel improvement, or just "bring back the free coffee!"
It also encourages every person to state what they think what went right or wrong publicly, a huge challenge to geographically dispersed teams.  The "right and wrong" would be anonymous, while the intensity/frustration/idea/looming issues field would be associated with the contributor.

Thoughts?  Is intensity/frustration the right axis choice to gauge the pulse of the project?

Comments

Post a Comment

Popular posts from this blog

Visualizing the user post migration paths across Reddit to extract linked communities

By -
Image
Someone was kind enough to crawl all of Reddit.com and produce a TB sized extract of all posts . This was cool.  I ran it through a small loop that said for each author if they post next in another subreddit (link strength from old sub to new sub)++" Then some trimming: keep the top 5 outbound connections from each sub, and top 20 inbound links.  Mix with some gephi layout and coloring , and voilà - how everything is connected! It would be fun to do a neurons firing lightning sort of animation - "pick a starting place based on popularity, and fire/light up one possible path the author takes from there"
Read more

Why people don't like Product Managers

By -
I recently attended p-camp , a fantastic get-together for product managers from all over the US. Hidden among sessions in the vein of "Agile Now!" and "Can you be more Agile?" and "Agile and Scrum: How to be more Agileriffic" there was a gem of "The Future of Product Management" where we explored where the career of Product Manager was and where it was heading. And what I quickly realized was that people don't like us much. Come again? Ok, people like PMs as individuals just fine. (Well, people seem to generally like me, and seem to like the PMs I've worked with) But in general, there is a greater than average distrust of the PM as a role in an organization. As it turns out, there are some perfectly valid reasons. Engineers: don't like being told what to do (who does, really), and they don't like having to guess how hard something is before digging into it. And they really hate having to stop work on one thing and swit
Read more

Inability to visualize the scale of our national debt

By -
With some needed brain-break time between recruiter calls, I wanted to visualize the national debt.  Inspired by the NYT tree-map visualization of our next proposed budget , and unsatisfied with the "if the national debt was dollars it would encircle the earth X times " type of answer.  I get it, it's big.  Very big. But, how big? So I started out with a nice slider (now easy in HTML5) and a picture of a crisp new $100.  (It's all about the benjamins!)  Apply some exponential math to the slider, and whammo... I crashed my browser. No problem, rookie mistake and I'm just exploring, let's have some stacks of $10,000, the amount of a federal bundle of $100 bills.  When the amount of images on the screen is too big, switch to the bundles.  Problem solved, right?  Wrong, browser crashed again. Er, ok. How about stacks of million dollars?  Easy, some casino had a stack in a glass case and everyone took pictures.  Stacks of billion dollars?  An artist put together
Read more