Free New SaaS Tool for PM’s: FindItFast

I’m proud to announce that Exertus has released the first edition of FindItFast – Project Manager.

FindItFast
FindItFast.com

This free tool gets PMs the information they need to address critical issues, quickly and efficiently.

Designed to be used on mobile devices like smart phones and tablets as well as on laptops and desktops, FindItFast contains a curated issue/resolution repository organized with topic and category tagging for fast search and retrieval.

FindItFast eliminates the tedious and time-consuming method of finding answers by using general search engines or combing through community sites. By providing not only human-reviewed links to do a ‘deep dive’ on the issue, but also proven, simple steps to achieve resolution, FindItFast rapidly presents an out-of-the-box solution, saving the PM valuable time and energy.

Exertus, Inc. now has 3 SaaS offering for PMs: FindItFast, deliverableROCKET and the CPR project health diagnostic. From one PM to another, you really should check these out.

New Exertus, Inc Focus and Website

The Exertus, Inc. website was due for a makeover.

The updated, lean, multi-device UI is reflective of the new focus for Exertus – to make the lives of project managers easier while increasing efficiency and effectiveness through free and subscription-based SaaS tools.

Much appreciation to April at The Perky Pixel for the graphic re-design and user experience input and to Zac at Steg Solutions for the continuing AWS devops support.

Readiness: The Path to Success or Disappointment

Check Boxes-20150512-Bing

It seems obvious: initiatives are successful in direct proportion to how ready the organization is to make them a success. But time and time again companies fail to realize full return on their process/technology investments because readiness is improperly defined or not defined at all. Here are 5 things that must be done to guarantee your organization is prepared regardless of the size or scope of the effort.

Audience: Executives who are expecting a return on their process/technology investments; Project Managers who are responsible for delivering successful projects.


Lunar Landing-Bing-20150518Start with one clear definition of success

Different aspects of the effort have different measures of success. Timing, budgets and quality each have different metrics. And still, a project successfully brought in at spec, on time and under budget that fails to be adopted is ultimately a failure. While a late, over-budget, enlarged scope project wildly accepted is deemed a success.

When developing your definition be clear, unambiguous and as simple as possible . Use “Land a person on the moon and bring them back safely.” as your guide to a clear, unambiguous and simple success definition (with credit to JFK).

The Charter or primary organizing document is the best place to memorialize this decision.

Identify everyone who needs to be prepared

Remember that a key group or individual who is not ready can destroy momentum and retard progress.

Augment the project’s Stakeholder List with Readiness info, and review and refine this list during the arc of the effort.

Pay attention to momentum and critical mass

Trying to jam in needed promotion and testing at the tail end of an initiative rarely achieves the same result as a deliberate and steady orchestration of messages over time.

Judiciously apply Just In Time methods to fill gaps.

Gauge-Bing-20150518Continuously test and gauge who is ready and who is not

Understand what each group needs to be ready.

Call it training, instruction, testing, assessment, temperature taking, etc., this activity can move readiness from an assumption to a documented fact.

It will also expose gaps.

Construct the communication plan from the outside-in

Every initiative needs a communication plan. Plans focused on communicating status and metrics typically do not address the social aspects of getting ready.

Do not underestimate the power of social interactions to lift or sink your effort. From water cooler gossip to company blogs, opportunities exist to leverage social interaction.

All communication must anticipate how the audience will interpret the message if it is to be optimally effective – an outside-in approach. If you find yourself hearing or saying – “we need to tell them” the focus is inside-out.

 

Readiness is the overarching critical success factor that any initiative has. But time and time again companies fail to realize full return on their process/technology investments because readiness is a negotiated or mandated event, rather than an orchestrated and validated precursor to success. The activities above will ensure everyone is ready to achieve success.

 

Cris Casey helps companies get ready. He can design and conduct all manner of readiness assessments as well as lead targeted risk mitigation efforts to rapidly bring about readiness. If you think you may have issues with readiness, contact Cris through Exertus at +1 866 575-2460 or by e-mail, casey@exertusinc.com.

Happy 40th Microsoft

Gates and Allen c1980
Gates and Allen c1980

 

April 4, 1975 Bill Gates and friends incorporated Micro-soft.

Here’s an excellent chronology of the seminal events in the history of the personal computer:  http://pctimeline.info/

Don’t Get Screwed by Scrum: #2 – Where Agile is Fragile

Bursting Soap Bubble

 

 

 

 

 

 

 

 

Agile methods (specifically Scrum) have inherent pitfalls that can readily derail even the simplest project. Here I explain why what happens outside of the Scrum team matters more than you would first think and what you can do to prepare for the inevitable. This is number 2 of a 3 part series, focusing on characteristics of Scrum that are essential to successfully using the technique.

Audience: Executives driving decisions about development tools and methods. Director-level and above who are charged with applying the Scrum method.

Adopting Scrum for your project effectively means enclosing the team in a process bubble. This is not an explicit requirement; it is a result of the method. The bubble normally contains the necessary artifacts (i.e. product backlog, burn down charts, etc.) and behaviors (i.e. daily scrum, calculating story points, etc.) to develop a solution. As long as the team has control over the bubble, they can move at a self-determined pace. But what happens when the process is disrupted or altered by circumstances or events outside the bubble? It slows down or stops.

bubble and pushpinSince the Scrum method calls for a small-group, cross-functional team approach, any activity that can’t be satisfied by the immediate team is a candidate for bubble bursting. Here’s some common technology activities typically outside the Scrum bubble:

 

  • subject matter expert availability
  • infrastructure requirements
  • security considerations
  • access to critical apps or data

Likewise from a business perspective here are some items that can have similar effects:

  • subject matter expert availability
  • conflicting governance/approval processes
  • capital planning and budgets

In fact, most if not all of the existing external factors that affect any project will affect a Scrum-managed effort, but with greater impact. This sensitivity to externalities is what makes the Scrum method fragile.

meteor

 

 

 

How susceptible is any project to outside impacts? The number of impacts is generally determined by the both the size and complexity of the finished result. Small, simple solutions have few external dependencies. Large, complex solutions have many opportunities for interconnections (and influences); exactly what you would expect in a typical risk scenario. But the risk can be exacerbated rather than mitigated if Scrum’s susceptibility to external issues is not addressed.

scrum penny batch exercise illustration

 

 

 

 

A 3 step process to reduce Scrum’s sensitivity to external forces:

  1. Work out potential cross-functional needs ahead of time. Develop and iterate through some likely scenarios to determine where needs outside the team will exist. For obvious reasons this is best done with the team.
  2. Understand and potentially renegotiate any organizational communication protocols. Depending on how Scrum has been implemented, existing communication protocols may not be conducive to the method. Identify where changes are necessary. To reduce confusion, codify and publish the protocols so everyone has the same reference.
  3. Map known service level expectations against the method. Using the scenarios from #1 and the communication protocols from #2, do the same analysis, but with an eye toward timing and the effect on Sprints. This exercise may affect the velocity at which the team can produce, but also the sequence in which user stories should or can be addressed.

The only way to protect the team’s bubble and defend against its bursting is to fully understand the risks. Risks not only to the project at large, but risks related to the method itself. For best results this needs to happen before the team actually starts. Skipping this activity hoping that the impacts will be small and manageable is not recommended. The good news is that over time and with practice, mitigating the risks associated with Scrum bubble bursting for your organization can become easier and easier.


I would love to hear about your thoughts on this piece. Please leave a comment.

Don’t Get Screwed by Scrum: #1 – High Performing Teams

 

A high performing team.
A high performing team.

A method and its benefits are soon parted if fundamental drivers are not understood and accommodated. Agile methods, in this case Scrum, has at its heart an engine some organizations struggle to establish and maintain: the high performing team. This is the first of 3 pieces on Scrum characteristics that are essential to embrace to successfully use the technique.

Audience: Director-level and above who are charged with applying the Scrum method.

For many years and in various ways it has been said that a mediocre team with an outstanding concept will produce a mediocre outcome, whereas an outstanding team with a mediocre concept will create an outstanding outcome. This is especially true for Scrum.

Companies adopting Scrum methods who short-change the importance of assembling high performing teams seldom realize the expected benefits, regardless where the method is used. I’ve seen this play out in a number of ways:

  • Expecting immediate results from teams that have no history of working together.
  • Diminishing the Product Owner’s (PO) role by inserting checkpoints or committee reviews where a PO’s unilateral decision is needed to maintain cadence and velocity.
  • Failing to staff the team with the proper functional roles.
  • Assuming distributing high-performing resources on multiple projects yields greater throughput.
Performance Maturity Curve (source unknown)
Performance Maturity Curve
(source unknown)

Creating a high performing team is not easy and usually not quick. In addition to understanding what the team will be producing and how they will individually contribute, they must also figure out how to work together; a process that depends on developing a shared work history.

 

Here are some ways to avoid disappointment (or worse) when considering Scrum from this particular angle:

 

  1. Realize that high performing teams are rarely formed on the first try. Building in buffers for re-alignment and re-assignment is prudent and smart.
  2. Build and test new teams with small, fast, low risk projects. Gauging performance based on delivery is the best and lowest risk way to identify a high performing team. Ideally this should be done before attempting a large, high risk initiative.
  3. Resist the temptation to divide high performers effort among multiple projects or across teams. This dilutes their effectiveness. Once high-performing team members are found, keep them focused on one initiative at a time.
  4. Keep high-performing teams together. All things considered, it is better to reassign a proven team to a new project than to break the team up. Again, teams need working history to get up to speed so naturally a fully-formed existing team is more efficient and productive from the very start.
  5. Remember that the Product Owner (PO) is a critical element of the team. The accuracy and speed at which the PO can articulate requirements, answer questions and make decisions has a direct effect on the performance of the team at large. Be deliberate and cautious in your selection and when defining the scope of the PO’s authority.
  6. Align policies and structures to incubate self-forming teams. Over time resources will attempt on their own to self-form into teams. This is in keeping with the Agile philosophy and should be considered a good thing. But unless organizational structures or policies permit this type of behavior, conflicts and frustration will arise. If this is not addressed, the potential for turning a high performing team into something appreciably less productive is a real risk.
Another high performing team.
Another high performing team.

 

How to Reduce Noise and Increase Signal In Meetings

Signal-to-Noise Graphic - 20150225

 

 

 

 

 

 

 

In science and engineering, the signal-to-noise ratio is a measure used to quantify how much a signal has been corrupted by noise. Informally, the ratio can be applied to discussions. “Signal” in this context is the delivery and exchange of content germane to the topic at hand, while “noise” is content that is off-topic.

For over 30 years I have been recording meetings. Over that period of time, no client in any context has requested the meeting not be recorded. And also in all this time, not once has the option of recording been explicitly offered or mandated. My supposition (albeit from a small sample) is that recording of face-to-face meetings is still rare in the business setting. This is a missed opportunity.

Having an audio recording at a minimum provides a number of obvious benefits:

  1. An index-capable reference for the creation of minutes, summaries or transcripts.
  2. A shared experience available for a wider audience.
  3. A tool for lessons learned.
  4. Frees up necessity of taking notes allowing potentially greater attentiveness.
Analog VU meter
Analog VU meter

But I have witnessed an even bigger benefit. The level of veracity and quality of discourse increases dramatically when people know that what they say will be recorded verbatim. In other words, the signal-to-noise ratio is very high. I’ve seen this happen time and time again. Whether it’s during internal client or client/supplier sessions, while most people seem more circumspect especially about making commitments, they also appear more open to discuss potential issues and opportunities – adding more signal than noise. That has been my experience.

Are all meetings worth recording? Probably not. The longer the meeting and the more active participants there are, the greater the need.

Critical Path Caveats

8 Activity Critical Path Example
8 Activity Critical Path Example

No one argues the concept of critical path is not valuable. But for it to be truly useful in a practical sense, embracing two fundamental characteristics is required.

The first characteristic is that the calculated path’s accuracy is in direct proportion to the accuracy of the plan or model. Critical path calculations depend on proper dependencies and realistic estimates. A lot (most) of plans that I’ve seen in the business process/technology space are missing key tasks, include arbitrary constraints and inconsistent estimates and do not have dependencies correctly defined. Putting undue emphasis on critical path items when the underlying plan is incomplete or incorrect can quickly cause improper resource allocation, scheduling issues or worse.

The second fundamental characteristic is that the critical patDiverging path out of the woods -  20140221h is not static. Semantically, most of us associate a path with a course or route which is assumed to be fixed. And at the time the critical path is determined, this assumption is true. But as the project progresses and the model changes, so does the critical path. An obvious change is that as time progresses, activities on the path get completed and the path gets shorter.

A non-obvious change is when the plan is refined with new, more current information or increased granularity and detail. One change in duration, a single revised dependency or a key resource shift can dramatically change the course and timing of the critical path. If the new path is never recalculated and reviewed relative to the prior path, the same outcomes caused by focusing on the wrong things can occur.

Managing to the critical path can work well as long as its use is tempered by the understanding that: 1) the path is only as reliable as its underlying plan and 2), it is a constantly changing thing.

 

The Information Technology Iceberg

Iceberg

 

 

 

 

 

 

 

 

 

 

Having been in the technical trenches I am very sensitive to electronic security issues. For example, my wife’s on-line shopping activity, game playing, and Facebook updating is on a different network from a different ISP than the network used for banking and business dealings. For any financial transactions (banking, brokerage, etc.) we use a single dedicated PC which is powered off until needed and is periodically replaced.

This Valentine’s day weekend was the scheduled replacement window. Preparing the new machine takes a couple of hours. This is the process I use:

  1. Remove any and all unnecessary applications and drivers, games, add-ins, freebies, etc., that come with the device. BTW – Acer does a decent job of keeping the push through sales to a minimum.
  2. Review and adjust Windows security settings.
  3. Start and configure Internet Explorer for private browsing, security settings, etc.
  4. Install and configure antivirus and firewall application. In this case Norton 360.
  5. Download and configure FireFox (from Mozilla) as the primary browser. Shutdown and restart the PC.
  6. Configure a printer.
  7. Run a complete virus/malware scan and optimize the hard disk.
  8. Set a Windows restore point (Win7 Pro Home 64-bit).
  9. Create a system image and repair disc.

At this point the machine is ready to be put into service. If you are keeping track, 3 websites have been visited: Microsoft IE default when IE is first started, Norton/Symantec and Mozilla. And two applications have been installed: Firefox browser, Norton 360 security suite. There is zero user data; no music, no pictures, no cookies, no bookmarks, no history, no downloads, no documents, no videos. Everything else belongs ostensibly to Windows and the concept of the Information Technology Iceberg.

The only thing we will be doing with this machine is using an Internet browser to access less than a dozen financial and governmental entities and occasional printing. No other browsing is allowed, especially search. The device that delivers this seemingly simple set of activities has the following (according to Norton 360):

  • 156,747 files
  • 1,398 Processes and Start-up Items
  • 581 Network and Browser Items
  • 5 Other

Remember these files and programs are less than what typically comes out-of-the-box and contain zero actual user data. This seems a lot like an iceberg to me. My piece is the statistically insignificant portion above the waterline where the app I will be using resides. Whereas the bulk of IT assets (software and hardware) are invisibly below the waterline.

The #1 Success Factor When Fixing a Troubled Initiative

 

Direction is important.
Direction is important.

One of my favorite stories of all time is about the turn-of-century (20th) logician and outspoken philosopher Bertrand Russell. Here is a rendition by Jacob Bronocowski from The Origins of Knowledge and Imagination, 1979:

“[Bertrand] Russell is reputed at a dinner party once to have said, ‘Oh, it is useless talking about inconsistent things, from an inconsistent proposition you can prove anything you like.’ Well, it is very easy to show this by mathematical means. But, as usual, Russell was much cleverer than this. Somebody at the dinner table said, ‘Oh, come on!’ He said, ‘Well, name an inconsistent proposition,’ and the man said, ‘Well, what shall we say, 2 = 1.’ ‘All right,’ said Russell, ‘what do you want me to prove?’ The man said, ‘I want you to prove that you are the pope.’ ‘Why,’ said Russell, ‘the pope and I are two, but two equals one, therefore the pope and I are one.’ “

Bertrand Russell circa 1960
Bertrand Russell circa 1946

So what does this have to do with fixing a troubled initiative? The first step in a realignment or recovery effort is what I call Diagnosis. The output of this step is a guess at what the root cause or causes of the issues are. It is the critical activity that defines where immediate efforts need to be taken as time is of the essence. It is where you need to ensure your propositions are consistent.

If this this step misses because the propositions are inconsistent, resources will be inefficiently or incorrectly tasked and time and money will be spent without addressing the root causes. There may be temporary improvement but sooner rather than later the initiative will find itself in trouble again and the process will need to be repeated.

This is why the Diagnosis step is the #1 Key Success Factor when trying to fix a troubled initiative. Get this right and you are on your way.