So far my blog is going slower than I imagined.  I started with an idea of what I wanted to write about – balancing the frequent project management focus on preventing failure through risk and process management with attention to techniques that bring out opportunities and engage people in making the project a success.  I wanted to organize my approach to the blog so that each piece fit into a well defined framework.  Anyone looking at it would say “Oh my, that’s brilliant!”  Well, it’s not happening like that.

I think that projects are always about achieving a balance between this and that.  This and that are many factors like the needs to balance quantity with quality, retaining ownership with transferring risk to vendors, inspiration and perspiration, investment in development capacity with operations and maintenance capacity, top down push with bottom up pull,  and the amount of change with risk tolerance.  If my blog is a project – I suppose it is until I get it going – then my current obsession with organization is out of balance with my need to write and share.

Maybe I can get more balanced by writing a post about balance.  I’m working with a project that is developing a new information system.  They are getting it done!  Using an “agile” approach, they defined what they wanted at a high level (user stories), prioritized, and are building it a piece at a time in two week iterations (sprints) by elaborating their requirements (use cases), building mockups of the system, talking it over, and then finalizing the piece and testing it in the sprint.  Final doesn’t have to be final in agile as decisions about what to work on are made at the start of each sprint.  That’s where balance comes into play.

As any information system evolves, you discover more about the problem you are trying to solve.  You realize that what you built last month could be enhanced to make it a better fit to the need.  So, do you spend your time to change what you’ve done or do you add as much new functionality as possible?  It can be a tough call.  What if you are working with a vendor who gets paid a fixed amount for successful delivery of each module?  In my example, the vendor has provided the client with a bucket of hours associated with the price bid and the client has to decide whether to go back and fix or move ahead.  Also, the project provides a framework that reserves time and effort for testing prior to moving a release (representing the work of several iterations) into operational use.  So the client and the vendor are also working to balance between pushing for more fixes and additions with sticking with the plan.  The vendor coaches the client in the agile process and pushes back when it feels its quality or capacity to deliver are being compromised.  How hard can the client push a vendor who wants to make them happy for more before getting out of balance?

Staying in balance in this case depends on maintaining trust.  Trust comes from building a contract defining how the client will express needs and how the vendor will provide for them.  It comes from a commitment to maintaining a win-win relationship.  It comes from open sharing of information about the problems to solve and what it will take all parties to solve them.  It comes from appreciating one another’s needs and strengths.  It comes from being accountable for commitments made.  It comes from striving for a perfect outcome and realizing that striving for perfect will get us closer but not all the way there if we want to finish something within our capacity.  It comes from having faith that our judgments, efforts, and products will be valuable.

I think that my client and their vendor trust one another to balance their push for perfection with stopping short of breaking the trust that has made for a productive partnership.  They will get as much as they can without losing value, faith, or money.  It won’t always be easy.

I don’t suppose expressing my ideas in a useful way will always be easy and organized, either.  I will keep at it and it will get better as I go.

Thanks for reading.

Copyright Glenn Briskin and “The Other Side of Risk” 2012