Monday, December 21, 2015

Get Good In, Get Good Out...and Keep BA's Happy!

So I saw this posting and had to share it.  Funny how the first thing I thought about was how it applied to business stakeholders and business analysis.


But think about it for a few.  How many times have you read a business case and wondered how in the world the person came to the conclusion!?  I love the business case of a 12 month project that was submitted, but revenue projections show that they will be bringing in revenue on the second month of the project when the product will not official be available for sale until at least half way through the project!  

The thought that if you act like an adult and think about what value means and how to achieve it and spend some thought about what it will take to achieve this, then you will get more scrutiny from the BA than our minion is providing here.  Yet time and time again I see business cases submitted with the same amount of energy as the decision making being done above.  

Picking the project with the cooler sounding name will only make you cool as long as it takes to read the title.  After that the metal hits the pavement and you have to produce.  Projects fail if they were not well conceived to even start with.  And I adamantly defend BA's that projects do not fail because of bad requirements, but because they were not even setup to scope ANY requirements.  Some forethought to consider what might be involved, even a simple checklist can save a TON of resources!

Get the businesses to consider a simple checklist before submitting any kind of proposal, whether major project or small work enhancement:

  • Is there IT components?  (Could there be IT components?)
  • Do we do this work in house today?  
  • What Legal issues are there?
  • What Compliance rules do we have to worry about?
  • Have we complied with Branding requirements?
  • Who will be my testers to evaluate the solution?
  • Do I know my budget?  Have I taken in account budget for any changes?
  • Who are the people who use this process?
  • Who are the people who support this process?
  • Who are the people who pay for this process?
  • Who has no clue about this process?  (Should they?)

And I could go on and on - but considering asking someone to look at these questions and for any question they do not know the answer to, then they must NOT submit their request and go find out.  A small checklist can save you a TON of time and headache from trying to work with a project manager to deliver an unrealistic project.  You may not be able to change the stakeholder's mentality but you can get them to consider a few conditions prior to asking for the world.  Then you'l be as happy as a BA with a 'bunch' of requirements!





Tuesday, September 22, 2015

Measuring Innovation

Image courtesy the BCG
To all my fellow innovation managers out there who are trying so desparately hard to measure the value of innovation in your organizations, I wanted to share something that struck me as so simplistic yet so profound that in and of itself, was truly innovative.

Rick Weaver posted an article about measuring project success and the impact Cloud services could have on these measures.  One of his measurements focused on an "Innovation Ratio" where we consider how much we are spending on reducing technical debts versus the amount of new capabilities we are adding.  More simplistically put:

                           Amount spent on reducing technical debts
      Innovation =  ------------------------------------------------------------
                                Amount of new capabilities added

To me we could keep this very simple on figuring out hard numbers of Innovation.  Consider what   are you spending to ensure your current technology does not become obsolete?  Are we buying the latest and greatest versions or upgrading legacy equipment?  Are we removing manual systems that lead to errors?

And then capabilities are easily accounted from a basic features list.  What can you do now that you could not do before is a great measurement for any change project or initiative.  Those are the benefits that are quickly tangible!   You can worry about culture change and measuring shifts in dynamics later once you have buy-in with your metrics!

So where to look for these things?  Again, keep it simple - where are you manually addressing processes?  Where are you using outdated technology (easy answer is where do people ignore the technology provided and instead use their own manual process - these are anyone creating their own spreadsheets and databases or emailing items or worse, printing!!)?

What ideas do you have?  Again, this equation struck me as a great way to help MEASURE INNOVATION and the value that you are bringing to an organization!


Monday, September 14, 2015

Building Leadership Skills on Project Teams

I recently had the pleasure of sharing this as a presentation at PMI HNL Professional Development Day 2015 and enjoyed the feedback that I've incorporated into this posting to continue to share and build on thoughts that makes us successful when working with people!

If you want a different outcome, ask yourself what are you doing differently to achieve this outcome.

Requirements

Understand that project teams are made up with people of diverse experience & expertise; while valuable to the team, realize that they each take a different view of the challenge at hand

Physically displaying items – whether in pictures of end result or large words posted on the wall – help clarify and ensure everyone is literally on the same page.




Consider “Draw the Pig” icebreaker – instructions available at:  http://www.whiteman.af.mil/shared/media/document/AFD-130408-056.pdf  



Risk
Draw out the potential outcomes (comic strips are great for actions) – how likely are they to occur?  Are they worth prioritizing? 




Getting Feedback
Post ideas on a large easel sheet of paper (one idea per page) and post in a common area.  Leave markers and encourage people to comment over a few days.  Great for identifying what’s in and out of scope!

Listening
Listening is about asking the right QUESTIONS (not the right answers – if you knew the answer, why are you asking the question?)
Listen to all the information the person shares versus focusing on just what you want to hear – you may miss out on valuable information!

Get a scribe – someone NOT a stakeholder to take notes so that you may engage with your stakeholders.  Then review afterwards with the scribe and highlight key insights from your listening.

Process Definition
How a process works is sometimes better to see in person.  If you can’t physically see the action then act it out (think charades!). 


Brainstorming
Use the “Red Cup” or other object – one idea per person, must say an idea before passing, can only say one idea and continue for a short amount of time with a hard time limit (push people to go faster!) – focus is on QUANTITY not quality.  It removes the “analysis paralysis” by focusing on the object while getting equal participation by all, regardless of position or expertise.  There are no right or wrong answers, just ideas to grow on.
     Question from presentation: Brainstorming in this way could still allow influence on others - YES!  Participants, even though the focus is on equal pariticipation by all, could still be influencing others; however, the goal of brainstorming is quantity.  If you're more focused on not influencing, then anonymous techniques (via email and a facilitator) or non-verbal techniques (using post-its on a wall) may be preferred.  Adjust to your situation!

Prototyping
Build something a user can interact with – SHOW what the envisioned end result is, do not tell them.  Give them something to interact with.

Prioritizing

Write out each item on a post-it, one per post-it.  Then provide stakeholders with poker chips (or other voting item) and have them vote.  They can place as many as they want on each, but no “buying” more.                                                     


Just TRY it!  And build on Lessons Learned!

Tuesday, June 2, 2015

Excellence in Process

I read a great article in a white paper by IAG Consulting that looked at requirements quality.  I love the idea that the process you use to gather the requirements is more important the the requirements you write.  They premise this on the idea that if you have a solid process to elicit the information, then you will end up with excellent information.  A great point back to the proverbial saying "garbage in, garbage out."

This is such a simple but important thought out to the world - considering your effort (quantity) and your level of attention (quality).  You can certainly apply this to requirements, but you could also apply to almost any activity in any profession!! (Creating scope documents and test plans for my fellow PMs and BAs certainly comes to mind!).

In our fast paced world we so quickly jump into requirements gathering with the excitement to hurry up and write down requirements as fast as we can.  We then spend plenty time going back and revising, editing, re-organizing, adding, editing, deleting and so on until we almost want to start on a clean slate!

What if BEFORE you jump into anything, you write out a quick plan on what you plan to do.  It does not have to be long, just a few minutes, but consider your stakeholders, where the information is today, what do you already know and what do you need to find out.

Consider going grocery shopping.  You have the approach to walk every aisle.  This often ends up with way more in your cart than you planned and often probably a lot longer (and more expensive) than you planned the trip.  You can try run in and just look in certain areas for a few items, finding yourself backtracking and forgetting a few items.  Or, as I often do, I create a grocery list throughout the week.  I then plan to go by the grocery store I'm familiar with at a time later in the week when I know it is not as crowded.  I then go in, get my items (and only my items) and am back out on my way home ready to cook dinner.

This same thought process, while small in comparison, can lead to much stronger quality requirements and project plans.  But too often we simply dive into the activity versus taking a moment and asking ourselves "How are we going to do this?"  Try explaining your process to a younger child - I love hearing their feedback as they will quickly point out any errors in logic!

Wednesday, May 6, 2015

Delivering Value

How are you delivering VALUE in all you do?

VALUE - an interesting word that is often talked about but completely missed in daily activities.  This only perpetuates the statistics that projects fail to meet objectives or campaigns fail to meet their targets - they fail to deliver the value expected.

Do you consider how you are delivering value in all you do?  If every person on a team constantly looked at how they are delivering value, would the team then end up delivering significant value?

Being part of a volunteer organization where every single activity is done out of one's own selflessness, I found it amazing the energy and effort put into providing value for the members.  People who all have full time jobs in addition to their volunteer must absolutely prioritize all that they do.  For the service organization, the challenge was put out to ask if every thing they do delivers value, especially board members.  You are serving others and if you are not serving their value needs, then your efforts are not delivering the value intended.

Consider every task that is brought up in your work or volunteer organizations and ask "Does this deliver value to our [customer/stakeholder]?"  If you have a hard time answering this, you may reconsider the task itself.  People in offices often talk about how busy they are.  I see it too, personally, that the amount of information moving around seems to create a buzz of activity.  However, I find myself asking if what I'm doing is adding value.  I found a few simple responses to help me get through my day more efficiently by considering "Am I Delivering Value if I do this task?"
  • If I answer "no" then I simply delete it and move on.  
  • If I think the answer is "no" then I delete it and move on.
  • If I answer "yes" then I prioritize it and do it as soon as possible.
  • If I think the answer is "yes" then I skip for now and come back after I do the prioritized "Yes" items
"But wait!! Delete?  No one deletes ANYTHING around here!!"  To this answer - if it is important, someone will bring it up again - guaranteed!  And remember what's important to you may not be important to others so you can skip the tasks, but the owner/affected stakeholder may find value and will continue to pursue it.  Often if they ask a second time that have more information that provides you the background to turn it into a "Yes" value answer.

What's interesting on the "think the answer is.." options - they are often all No's as either it's clear that you can not articulate the value or you do not have enough information at this time to answer Yes and until then you do not understand the value.

Tricks to try and would love to hear other ideas and thoughts!!!