Subscribe via RSS Feed

Tag: "getting predictable"

Winning with “Project SD”

Winning-with-Project-SDEvery team needs a process they can embrace because they know that process will get them to the desired result.

What Drives The Getting Predictable℠ Best Practices?

startIt’s all in the phrase: From the Start. I am frequently asked how the Getting Predictable Best Practices got started.

Getting Predictable℠  best practices cross many subject areas including requirements collection, tracking project progress, facilitation techniques, providing estimates that drive confidence, and so on. With such a wide array of practice areas, you’re probably wondering what binds them together. In other words, is there a common theme or vision that drives current and future best practices and recommendations? The answer is YES – there is indeed a common theme. And, as you guessed, this blog post reveals the vision aligns Getting Predictable℠ in all of its many flavors from discovery to definition through execution.

From the Start

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Wow! How profound! (Yes, I am being sarcastic at the moment but there’s truth here as well) For the majority of my career I have been on the client side of consulting relationships. I have heard some pretty big promises and I tend to be very skeptical. As I read my own description of Why Getting Predictable℠ exists, it’s hard not to think how empty it sounds! So let me explain. Let’s pretend we have a project kicking off and we have approximately four weeks to collect the overall requirements so the technical team can begin their planning and staffing of the project. So we e set up meeting with key stakeholders and business users for the first week in March to kick off the requirements gathering. The business is extremely busy and coordinating their schedules is like herding cats. All too frequently, you do not get full traction and commitment from the team during the first few days. In fact, it is possible that you might not get to full throttle until the second week of the four week schedule. Since we didn’t pad our four week plan, this lost time needs to be addressed. It is important for us to be adaptive and stay on schedule despite losing three to five days at the beginning. I want to emphasize that is not a rare situation. Especially when launching a new initiative. Would you agree?

Let’s take a different perspective…

Let me share a different way to view this. It may be a day here or a day there, but if we actually lose four to five days getting up to speed across the four weeks, we have lost 25% of schedule. We are potentially 25% late and over budget for this phase. And we haven’t even started yet! Here is my point: Although most of our leaders and managers would never intentionally handicap or put the team at risk, they are unaware that missing a meeting or pushing a date is actually doing harm to the team. If this story, in one flavor or another, resonates with you, then your success and the success of your project are being put at risk from the very start of your project. Why does this happen?

It’s all about the frog

If you put a frog in boiling water, it will immediately jump out. It’s way too hot. But if you put a frog in room-temperature water, and very slowly turn up the heat to a simmer, the frog will stay in its comfortable hot tub until it perishes. Ouch! On your project, it may only be a day here or a few folks there, not available, but before you know it, your project is starting to simmer. So let me repeat:

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Getting Predictable best practices identify and address the situations, activities and events, that can slowly handicap the teams chances of success before they even get going.

Now You’ve Got My Attention. Tell Me More.

Getting Predictable℠ Best Practices cover the gambit: Discovery, definition, execution, and organizational effectiveness models. In this blog, I focus on the best practices that address defining and launching a project or initiative. I call this set of best practices Getting Predictable℠ Definition. Getting Predictable℠ Definition addresses the three key areas that impact a project right from the start:

  • Alignment: Driving alignment around project success across all stakeholders.
  • Commitment: Developing estimates and plans the team can commit and manage to.
  • Visibility: Having a common view of progress as well as a a common definition of when the team has delivered on the defined project objectives.

In my next posts, I will discuss each of these areas in detail so you can see there is a method to the madness of Setting Teams Up For Success FROM THE START.

Measure Twice, Cut Once

The Role of the QA in Making Software Development Predictable

measure-twice-cut-once1A Guest Post for the Getting Predictable Blog

Measure Twice, Cut Once is about having a plan, being prepared, and having a systematic approach before taking action. Whether it’s installing new cabinets in your kitchen or writing a new software application for a client, no matter what type of project you’re working on, you can minimize your chance of making costly mistakes by double checking your measurements/requirements before cutting materials or writing code.

I learned this very valuable piece of information growing up with a mother who loves to sew. As a kid I would always ask my mom if I could help. Since sewing requires measurements to be as accurate as possible, a standard practice was enforced when working with my mother to double check my measurements before I cut anything! I always thought the reason she made me double check everything was because I was a kid, until one day I noticed my mom double checking her measurement as well. So I asked her, “Why do you measure the fabric twice before cutting it?” My mother replied (as she continued measure every part of the fabric), “Because this fabric costs too much and my time is too valuable to be wasted.”

She continued to say, ”Let’s say I cut too much fabric. I have now wasted fabric because I have to cut off the extra fabric which takes time. Or, let’s say I cut the fabric too short. Now all that fabric is wasted and I must cut a new fabric layout which also takes time…”

“This dress should take me one day to make but if I’m constantly re-cutting fabric due to measurements being off, then it can take me twice as long. My original estimate of how many outfits I could get out of it will also be off. Plus, I will have to go back to the store to get more fabric. But if I just double check my measurements I save myself time, money and a headache.”

QA. (not to be confused with Tester)

This is true for IT projects as well. If the requirements (which are the measurements for a software project) are being doubled checked, the project will have a minimal chance of wasting resources, time and money.

One approach to ensure that this double check is being done is to get the QA involved at the requirements stage. While having a tester involved at this stage is not the most efficient use of resources, having a Quality Assurance Analyst (QA) definitely is.

Many IT professionals are not aware that there is a difference between a QA and a Tester. A QA is an IT professional who makes the blueprints for processes and procedures. These blueprints will ensure quality is maintained throughout the lifecycle of the project. A QA also understands how to design test cases in a way that they are competent, effective and easy to execute. A tester is someone who executes test cases that, in some cases, have been written by a QA. If a QA is involved with the requirements stage, the requirements will be unambiguous and succinct.

The QA will also check the requirements to ensure that the following has been covered:

  • Look and Feel: – How does the interface make the user feel and behave?
  • How and why the system works: What will happen when this button is clicked and why?
  • Contradictions among scenarios: Does one scenario say the opposite of another scenario?
  • Root causes for gaps in the system/process: Are scenarios defined well enough? Is the workflow depicting a different picture than the information given?

The more robust the requirements, the better the final product.

During the requirements phase, the foundation that the entire project depends on will be formed. Given that over 50% of project defects are introduced during the requirements gathering phase, it makes sense to have a QA involved to double check that gray area requirements do not get overlooked and to help define error messages and usability issues. Just like a sewing project, fundamental issues left unchecked will surface later in the project.

“Measure Twice, Cut Once” is a reminder that careful project planning will result in more predictable results.