benchmarking reveals the fingerprint of a new system

Benchmarking is a valid, powerful and concrete way to compare a new system or process to the current, “as-is” state OR to compare multiple systems in a vendor selection process. To ensure each of those adjectives (valid, powerful and concrete) are met here’s some suggestions:

1. Valid – ensure a level playing field in all systems evaluated – think “sameness”!  The same approach, conditions and evaluation guides need to be used.  Many years ago, while benchmarking systems for Nebraska’s first Automate Fingerprint Identification System for the Nebraska State Patrol (circa 1994) we included fingerprints that would match, partially match and had zero probability of matching.  One vendor objected to the zero match fingerprints (called latent fingerprints).  We held firm in the benchmark and onsite testing – in part that two other vendors had already complied.
2. Powerful – benchmarks of the current process, user interaction and system performance ensure that new systems can be fairly and completely verified. This is powerful and makes for an apples to apples comparison.  If the current system provides 99.99% up-time and less than 2 hours for return to operational state, then all replacement systems can be held to that standard, OR BETTER!
3. Concrete performing benchmarks is a concrete way to see a set of requirements in action.  A few years back (2004) I facilitated a vendor review for a modernization of a large state agency unemployment insurance system.  Three leading vendors had pitched all sorts of cutting edge development frameworks, tool sets and approaches – it was at benchmarking that the complexity (or over complexity) and mismatch was found.

Benchmark away!  Capture metrics for quality, quantity, speed of your current system and maintain those metrics. They are the seeds for benchmarking.

Related articles

• Benchmarking (managedvideoblog.com)
• Business Analysis Technique #5 – Data Dictionary and Glossary (tapuniversity.com)
• Business Analysis Technique #4 – Business Rules Analysis (tapuniversity.com)

One a hundred problem tracking tools and a personal favorite - BUGZILLA!

Problems, issues, bugs, defects, action items, punch list, clean up tables – so many synonymous terms for the same underlying concept – tracking known “stuff” and making sure it gets resolved before a product or service is released.   While risk management concerns the known- unknown, management reserves address unknown  -unknown, problem tracking is smack dab in the middle of the here and now.  It’s real!

As there are multiple ways to describe it, there are also dozens of tools to track it.  Over the course of my delivery I’ve used Defect Tracker, Bugzilla, RUP, Spreadsheets (Lotus, Quattro Pro, Excel), Public Folders (Microsoft), Silk, Mercury Tester, Sharepoint, Quick Place and large flowing legal pads with a thing called a pencil.

While using those tools I’ve found a few simple tips help to keep my and my team’s attention focused.  I use the term “AIR”.  It helps breath some fresh air across this stuff and make sure the mildew does not mire your project down!

1. Create a category for Action Items (issues or problems that have been assigned to a single person with a specific date)
2. Create a category for Issues / Problems (issues or problems that are known and may transcend your current project or change order)
3. Create a category for Risks (issues or problems that have not yet occurred but you’ve deemed may occur).
4. For Action Items and Issues / Problems assign an impact rating if it is not addressed.  The probability is equal to “1″ since it’s a known.  The decision support is how much that issue will impact your project.  Higher impact issues rise up in their priority for fast assignment to an Action Item
5. Keep the AIR up-to-date with any project scheduling tools you might use (Project, Clarity, etc) – a project schedule is a collection of Action Items (aka tasks).
6. Review the most pressing, the top 10 action items, issues/problems and risks with your team regularly.  That could mean reviewing those once a week or, if you’re in the midst of an Extreme Programming or SCRUM or similar Agile approach, every day.
7. Use this to help guide your product and service launches.  Transfer any lingering problems/issues to the operational support team.

Related articles

• Considering a new keyword for Bugzilla (whereswalden.com)
• Project Health Check : 5 serious project warning signs (tapuniversity.com)
• Business Analysis Technique #26 – Scenarios and Use Cases (tapuniversity.com)
• How to Find Where New Process is Really Needed (tapuniversity.com)
• 22 Free Tools for Data Visualization and Analysis (pcworld.com)
• Business Analysis Technique #32 SWOT Analysis (tapuniversity.com)

Social Networking - what has the world gone to?

SWOT Analysis (Strengths, Weaknesses, Opportunities and Threats) is a venerable mainstay of management and MBA
curriculum.  While it’s typically applied at the organization level for strategic management, SWOT analysis can be a helpful technique for understanding the business perspective for a set of requirements or a project. It’s described in 9.32 of the BABOK™

A SWOT analysis also can be a wonderful technique to use to cultivate a group conversation – whether it’s with a laptop and projector, flip charts, dry-erase board or post-it notes – it’s a quick way to focus a group’s attention.

Here’s a sample SWOT analysis for Facebook.  Let me know what you think, agree or disagree?

Related articles

• A SWOT Analysis for Social Media in Libraries | Online | Find Articles at BNET (findarticles.com)
• SOAR, Don’t SWOT! (canyoulead.wordpress.com)
• SWOT analysis (tobysba.wordpress.com)

Just a little bit of risk that needs to management

Step Two of Resolving Virtual Team Conflict is to treat it as a potential risk.  The advantage of looking at team conflict as a risk is it’s an easier to say “hey let’s treat team conflict as a risk element, something that might happen” rather than “gee, we’re conflicted and at each others throat, upper management help!”

The following table is taken from a real life project at a dot.com company in 2001.  As with other projects at this start-up, the project was ripe for conflict and full of risks.  While the technology as leap frogged ahead in 10 years, the issues with virtual teams remain.

The purpose of this project was to deliver an innovative solution to a large software company.  It required an “all hands to one side of ship” approach using brute force to complete.

Unique was that resources were distributed across three locations, Silicon Valley, Shanghai and a Midwest Operations Center.

Conflict was included as a potential risk element and mitigated through structured, consistent communication (via conference call, Internet chat, web conferencing and shared document store).  This approach helped achieve an ambitious and high risk, release to market.

See Table 1.

Table 1.  Risk assessment with conflict element

This may be you, right now. Or if not, in your near future!

Virtual teams are geographical dispersed teams (GDT) who are formed for a variety of reasons.  Sometimes the virtual team is formed as a result of mergers and acquisitions (M&A), or a collaboration among organizations may trigger it, perhaps a key employee moves or a company wishes to get some “boots on the ground” in a new city.  Regardless of the motivation, virtual teams are a given in a dynamic global community.

The Fourth Edition PMBOK references virtual teams as a tool and technique for Acquire Human Resources (Section 9.2).  That single tool and technique can produce a wealth of questions for the PMP exam.  From conflict, to communication overhead, twenty-four hour work cycle and requirements gathering challenges – there’s a long list of topics to discuss and validate.

Virtual teams are a practice area for TAPUniversity.  We have studied them and helped others become proficient in managing them since 2005.  Frequently traditional management wisdom does not apply and may even back fire.  Virtual teams also have proven a sticking point for the Agile SCRUM movement, which, in its initial manifesto, had co-located teams as key principle.  Over the next few weeks we’ll dig deeper and share more about virtual teams.

Please share your experiences as well.  What’s worked well?  What hasn’t?  What’s changed for you in the last ten years in working with virtual teams?

Don't let a plate or estimate fall!

Schedule (Activity Duration or Activity Resource) and Cost estimating are two lynch pins for business analysis and project management. The most common estimate techniques are: analogous, bottom-up, parametric and three-point – PERT.

For those pursuing a CBAP® or PMP® how to use them and whether those are mutually exclusive can become a bit confusing.  The hundreds of exam banks for the PMP® exam often seem to force a PMBOK® based exclusion (see Sections 6.3, 6.4 and 7.1).  That is not accurate.   The estimates for schedule and cost are in practice used together and also not presented as mutually exclusive on the PMP exam.

Now for a quick review of how the four estimate types might work together.  Let’s use a swim meet as an example.

• Analogous estimate - just like the root word analogy implies, analogous estimates are based on a previous project(s) within the organization.  This estimate is often the earliest and most convenient one to gather.  Because of that it is often used to justify a project and for project chartering.
  Example when I help conduct a swim meet we have an intuitive sense of how long a meet of 50, 100, 150, 200 or 250 swimmers will take.   My role is typically whatever is needed and most often starter, referee or stroke and turn judge.
  For a meet we conducted Saturday – based on 210 swimmers for over 70 events with a 20 minute break – our analogous estimate 
  

  Lining up swimmers is like herding cats into the water.

  was 8:30 a.m. to 3:45 p.m.  The various swim meet official team members were a bit nervous when official entries received by Wednesday were 50 more than anticipated.  So our analogous estimate that had been 8:30 a.m. to 2:00pm was revised upward.  Adding a bit to our anxiety was the threat of winter storm (two teams were traveling over 50 miles).

• Bottom-up estimate – this estimate gathers cost or schedule from the resources or subject matter experts (SME) involved in performing the activity.  The idea is rooted in quality management – those that do the work really  have the best idea of what is involved.Using the swim meet example again, we ask coaches, those that help line up the swimmers (clerk of the course), time (timers), judge and officiate  how long each stroke (free, back, breast, butter fly, individual medley and relays)  might take and then use those estimates alongside seeded times for each swimmer to create a schedule.
  For that Saturday meet – our bottom up estimate was 8:30 am to 2:52 p.m.
• Parametric estimate - this estimate looks at aggregate estimates from across an industry.  A treasured pocket-book of mine is the Wilson’s pocket estimator (circa 1985).  It’s full of construction estimates for time and resource load, from plumbing to drywall.  I used it for estimating paint jobs during my undergraduate work.  Visiting the swim meet example. the USA Swim Association and YMCA swim governance offer guidance for indoor and open water swim meets.
  For that Saturday meet the YMCA swim guide estimate was 8:30 to 3:30 p.m.
• Three-point/ PERT (program evaluation and review technique) - this estimate typically is used with the other three techniques to develop a pessimistic, most likely and optimistic schedule per activity.  We did not apply this to every activity (event/heat) for the meet.  I did do a quick three-point for the 25 yard events (where timers move from one side of the pool to the other).  The timer travel time took anywhere from 90 seconds to 4 minutes (quite a range) with the most likely or mean travel time of 3 minutes 10 seconds.  My quick 3-point estimate was 2 minutes 53 seconds.

SWIM MEET Actual – the meet went from 8:30am to 3:18 p.m or within the estimate range. The meet was ahead of the bottom-up schedule in the early morning due to combining two 500 yard events into one.  The meet fell behind the bottom-up schedule in the late morning as the 25 yard events were conducted (a dummy activity or lag for timer travel time was not entered).

So what?  As you incorporate the estimating techniques, incorporate all four if possible.  Analogous and Parametric estimates are found by asking someone in your organization (analogous). Nimble use of “Google” will help find your industries Parametric estimates (e.g. COCOMO for software development or Wilson’s estimator for construction).  Bottom-up involves talking with key resources and getting a sense of who will perform that activity for your project (for example a new team member will not produce as quickly as a 7 year SME).  Three-Point / PERT can be used selectively for higher risk activities or ones that you want that second look.

2010 Stats for the TAPUniversity Blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

About 3 million people visit the Taj Mahal every year. This blog was viewed about 43,000 times in 2010. If it were the Taj Mahal, it would take about 5 days for that many people to see it.

In 2010, there were 108 new posts, growing the total archive of this blog to 361 posts. There were 21 pictures uploaded, taking up a total of 3mb. That’s about 2 pictures per month.

The busiest day of the year was March 15th with 265 views. The most popular post that day was Conflict of Interest and the PMI Code of Ethics .

Where did they come from?

The top referring sites in 2010 were en.wordpress.com, onprojects.net, linkedin.com, google.com, and google.co.in.

Some visitors came searching, mostly for pert formula, stakeholder register, stakeholder management strategy, estimate at completion, and project exclusions.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Conflict of Interest and the PMI Code of Ethics March 2010

Project Exclusions, Assumptions, and Constraints April 2009

Estimate at Completion – Using CPI and SPI Method August 2009
1 comment

PMP Exam – PERT Formula February 2009

Earned Value Management – CPI and SPI August 2009

How a problem is defined will affect how it is solved

Take a theoretical example: Many companies conduct staff engagement or satisfaction surveys. These surveys are designed to measure how engaged, satisfied or motivated their employees are. If an organization has “bad” results on its staff survey, leaders and managers are likely to want corrective action to be taken. After all, nobody wants unmotivated employees.

The first step to addressing the issue is to define and frame the problem. Often this framing process happens unconsciously, but it is significant as it impacts the way that people interpret and respond to it.

The two questions below are ways of framing the problem described above. These two questions look similar on the surface, but they are actually incredibly different:

1. “How can we improve the staff survey results?”

2. “How can we make this a great place to work?”

In my experience, organizations ask question 1, which focuses on the symptoms. In the staff survey example above this might involve identifying key themes, and perhaps corporate communication is one of them. The organization responds by starting newsletters, having “open door management” policies, but the culture doesn’t really change.  The executive team look at the metrics “How can we move from 10% on the satisfaction scale to 15%?”. They apply palliative measures, and the root cause is never even investigated, let alone resolved. The objective becomes about improving the figures not improving the organization.

Organizations really need to ask question 2.  They need to investigate the systemic cause of the issue – accepting that the symptoms might only be the tip of the iceberg. This might require a change in the organizational culture and will certainly require observing the organization as a complete system. Question 2 opens a can of worms. It requires stepping back from the metrics, and that’s an uncomfortable thing to do.

This is just one (albeit complex) example.  Problems are defined and framed every day in organizations – perhaps in an operational context, or perhaps in a project context.  Thoughtful and robust problem definition and framing change the way people think about the problem, and open up new solutions.  As change practitioners, we should encourage and facilitate this kind of thinking – asking challenging questions can be incredibly valuable!

How do you go about defining and framing problems?  I’d love to hear from you- please feel free to contact me directly or add a comment to this post.

About the author : Adrian Reed is a UK based Business Analyst, author, speaker and qualified practitioner of change. If you enjoyed this article, you can follow Adrian on Twitter or read his personal blog.

Kudos to Learning Tree for a very cool CBAP display!

In terms of professional associations it’s a new kid on the block.  Yet in a short time it’s made a profound impact on the discipline and profession of business analysis.

One success factor of The IIBA for making a swift impact has been embracing other best practice association’s bodies of knowledge (BOKs).  The primary body of knowledge that The IIBA and its Business Analysis Body of Knowledge (BABOK®) reference is the Project Management Body of Knowledge (PMBOK®).  That, in our opinion, is a good thing.  As best practices, BOKs, standards are established, allied or “nexus” organizations do well to embrace those competencies and not re-invent the wheel.

Risk assessment and management is an example of the BABOK®’s inclusion of the PMBOK®.  The full definition of it is in the Technique Chapters (Section 9.24.5).  Much of it repeats verbatim from the PMBOK®’s risk identification and management chapter/knowledge area (Chapter 11).  That definition provides one addition to the PMBOK® – specifically the further elaboration of risk tolerance.  Three categories of risk tolerance are provided:

• Risk-Aversion
• Neutrality and
• Risk-Seeking

Those tolerances may be applied to people or organizations.  Understanding the risk tolerance of either people or organization guides the building of risk management approaches for enterprise analysis, requirements management and organizational readiness (for solution implementation).   For example a risk averse organization typically does not embrace leading edge technologies.  Business Analysts in those organizations may want to opt for incremental improvement with proven technologies or approaches.

Related Articles

• Risk from a Business Analysis Perspective (tapuniversity.com)
• Risk Management Approaches (tapuniversity.com)
• Risk Priority Number (RPN) (tapuniversity.com)
• Business Analysis Techniques: 72 Essential Tools for Success (deurainfosec.com)
• January 25, 2011 Risk Management: Protecting Your Business and Profits (learnedatscore.wordpress.com)

The Risk Priority Number (RPN) helps focus attention on the top 10 or 15 risk events that may occur.  Once an RPN has been established, proactively monitoring risk conditions kicks in.

For example consider that following risk event might - delayed shipping due to transportation availability.

During the busy holiday season, Ted notices that receiving his favorite reference book for his students can slow down to a crawl (Norm Abrams “I Am the Nails of Woodworking, Bob Villa was Just a Cover”, 2004).  His  standard shipping may take 5 to 6 days instead of normal 3 day process.  He normally freezes enrollment on Tuesday night to ensure sufficient books (but no more than necessary).  His classes fills at 12, but he will run them with 5 students.

To proactively manage this risk, Ted can do a few things:

• either order more books than needed for his next class (not a really “lean” adhering practice and
  

  Ted's woodworking

  likely to drive up fixed costs) or

• for a 25 day period, pay 2% more for expedited, two day delivery (driving up cost but on a variable cost basis).
• enforce a Tuesday registration (this may prune his student list by 2 or 3 since his classes are often an impulse decision)

Ted opts to pay a little extra to ensure timely deliver without adding excess inventory.  This simple risk management strategy can be applied to more complex situations and scenarios.  The key is to balance the possible solutions and impact, comparing the pluses and minuses.  This management strategy also helps to unearth secondary and residual risks (for example expedited shipping may result in higher than normal damage to Ted’s reference books.)