Decrease Certainty - Increase Agility

We’ve been adding more Agility into our production process here at Vertabase.  As product manager, I’m leading this effort.  One of the techniques I’m using is to push-back at the development team when they ask me questions, particularly about features.

One of my favorite responses is “Do I need to make a decision on this now?

The urge to make a decision now is strong, coming from a plan driven background. But it unduly locks-up the team, our customers and our product.

While it is comforting for the team to have me (or a customer, for that matter) make a decision, it makes them less nimble and responsive. It focuses them on meeting a set of requirements, as opposed to the customers’ needs. The responsibility for the feature is no longer in their hands. They can simply follow directions and meet a spec.

So far, the team has been empowered by seeing that a decision doesn’t have to be made nor a policy/spec adhered to, and re-focused instead,  on the simple art of the right feature implemented well.

The Speed of Light, AIDS and How We Can Improve Projects

Two remarkable events in the scientific world over the past month shed light on how we can improve projects and deliver the right solutions.

The decoding of an AIDs protein and the publication of the CERN findings on a faster than light particle.

These are incredible accomplishments in their specific domains. However, what strikes me as particularly relevant from the project management perspective is the context in which these events are happening.

They each represent changing paradigms about the context in which knowledge is created. Decoding the AIDS protein occurred under conditions where the data was made public, where strictures on applicable problem solving methods were removed, where the downside implications of a team’s failure were minimized and where there was sufficient information to approach the problem yet not bias potential solutions.  Creativity, cross-domain sharing of tools, techniques, knowledge and processes occurred, and people were rewarded (either externally or by an internal feeling) just for trying.

This is a powerful model for the kind of environment we can create on projects and throughout the life cycle of the project’s objective (its product, service or result).

Similarly, the CERN announcement represents a blended paradigm of traditional scientific knowledge creation melded with an open approach.  The CERN scientists are asking for the world to go at the data to disprove or confirm the results.  There doesn’t seem to be a traditional, silo based aspect.  Given the magnitude of the discovery (and the fact that it was experimentally derived rather than theoretically) the team is putting it out there for the world, professionals and amateurs, to approach.

Take note, having empirical data makes it easier to share the problem across domains. The data, like in the AIDS protein example, becomes a boundary object for cross-domain sharing.

On projects, we can encourage this kind of approach by creating true boundary objects (and not just project artifacts that pm’s, engineers or other specialists can understand).

Creating an environment and artifacts that foster meaningful and useful communication can have a significant impact on the success of the project’s objectives to meet the underlying goal /problem that sparked the project’s initiation.

A Quick Estimate Can Save You Project Headaches

Formal project management methodology can be overkill on some projects or a lifesaver on others. In general, it’s clear on when to go through the detailed steps of a methodology and when not to. It depends on the overall size of the project.

  1. A short project doesn’t require much in terms of formal project management. The steps you’d go through in putting together all the documents and spreadsheets of a methodology are done automatically as part of getting the project done.
  2. A long project should go through formal project management steps to make sure all bases are covered and that nothing is dropped or forgotten. (This is especially true during when gathering requirements for the project.)

The problem comes when you think the project will be short and it turns out to be a long one.

To avoid this, do a quick, 10,000 foot estimate on the project’s size before getting started. In the language of formal project management (like PMI’s Guide to the PMBOK), this is called a top-down estimate. It can be based on experience and past projects you, or other people in your organization, have done. Templates or archives of these past projects can be helpful sources of information for the estimates.

Take the time to actually put together an estimate, as opposed to just eye-balling it or basing your estimate on “gut” alone. It can save you from the headache of underestimating the tools, resources or information you need to get the project done.

Picking a Project Management Methodology

We were having an internal meeting to pick a project management methodology for a web project we are working on for a new client. As developers of commercial software, our instinct was to lean towards an agile based approach where our process would be:

  • Make an initial feature list
  • Get time estimates on each feature
  • Prioritize the list
  • Time box the development effort
  • Build and test as much as possible in that time
  • Launch
  • Get user feedback

This works great for a tightly defined set of deliverables and a client who has done software before. However, that’s not what this project is nor the profile of this client.

Read the rest of this post »

Follow me at: twitter LinkedIn

Subscribe to RSS Feed

Get the feed!


Add to Google



Get More Done



As Seen In

"Mark is a skilled communicator, and his blog stands out for its clarity. The ideas he presents are fresh and give readers a different perspective. Importantly, it gives practical and applicable insights."


- David Gurevich, PM Exam Guide

"An amazing talk!"

"Wonderful, engaging speaker!"

"Great insights."


- Audience reviews, Ann Arbor

"Mark is undoubtedly an expert in project management, not only at the theoretical level but at the practical level, as he is able to clearly explain and show how small to medium businesses can implement practical project management solutions to save time, money and headaches."


- Brian Love, CTO, Webucator

"Mark’s presentation style is engaging. Many people (particularly the Project Managers present) left the presentation eager to apply Mark’s advice on better planning and project execution to their own projects."


- Bernie Dolan, Sun Life Insurance

"Mark went out of his way to give a "real-world" talk on project management that was motivating and informational. Several of our group member filled up notebooks with great tips and takeaways from Mark's talk. I would highly recommend Mark for any discussion on Project Management and his talk is great for any audience."


- Matt Schulz, PMP, CIW

"Mark gave a very engaging presentation. He demonstrated his expertise in project management and provided some excellent ideas that our members took away from the discussion to try putting into practice in their own project teams."


- Troy Pullis, Minneapolis/St. Paul

"Mark came to speak about Project Management and Time Tracking. Mark eloquently delivered, a well researched, and comprehensive presentation that everyone found very useful. Mark no doubt is an expert on project management, and that is very clear when he speaks."


- Pete Freitag, President, Foundeo Inc, New York

"Mark was a great speaker, and I hope to have him back to Cleveland."


- Brian Meloche, Cleveland

Archives

1999-2012 Standpipe Studios, L.L.C., All Rights Reserved.

Trademarks | Privacy | Sitemap