Subscribe via RSS Feed

Tag: "Requirements"

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.

Facilitating A Panel Is Not So Different Than Facilitating A Requirements Session

My First AHA Moment of 2012

panel-discussion-150x150Facilitation appears to be a hot topic these days. After blogging about facilitation a few months ago, I am getting many questions about best practices and how to handle certain situations. At the bottom of this post I’ll provide links to my past articles on facilitation that should address many of these questions.

Today I want to share an AHA!

Recently I was invited to speak at an event on the topic of facilitation. One of the other presentations at that conference was a typical panel presentation.

Panels are very common at conferences; they usually have three to four people and a designated moderator who helps facilitate the discussion among the panelists and engages the audience. The session typically runs about 60 minutes.

These panels tend to be very dry (yawn)

For most panels, questions are devised ahead of time and shared with the group so they can prepare their agenda, personal messaging, and so on. I should clarify, that some panels are engaging and are very interesting. But at times, I come across a panel where each person seems to be coming from his or her personal point of view. Their views may not be clearly aligned to the question. So you get someone speaking strategically, while another may be extremely tactical or even not directly speaking to the question.

Let me magnify my point. Each member of the panel will work with the moderator to identify the question(s) they would like to be asked so they can share their viewpoint on a topic. And since three or four different panelists do this as individuals, possibly at separate times, it can be dry, without a clear set of takeaways.

I want to be clear, that there are many panel presentations that are engaging and valuable. But more often than not, I personally find them dry. As an audience member, you are trying to get a grasp of the discussion topics and understand the panelists’ points of view. However the very disparate nature of the moderator’s Q&A prevents engagement between the audience and the panelists.

Changing the dynamic of a panel…

This makes me want to try something new the next time I am invited to be a panel moderator.

I would want the audience to engage more with the panelists on stage. To get more energy, the format of the panel would have to be a little different. We are used to a panelist getting asked a question, then answering their question, followed by each of the other panelists attempting to provide answers to these preset questions which they may or may not have a valuable answer for. Then it starts all over when the next question is thrown out.

With my new approach, after the question is asked, instead of always asking all the other panelists to answer the same question, I will ask the audience members to give their perspective on the panelists’ thoughts. This would raise the engagement level of the audience with the panel.

My job as a panel facilitator would be to facilitate the rhythm of the discussion between the audience and panelists. This means I must meet with the panelists before the conference to create an agenda that would allow us (facilitator and panelists) to agree on a common objective. This would enable the panel discussion’s rhythm to flow more smoothly, be less fragmented, and not break the energy of the room.

I have already outlined in past posts, that the key to the most effective facilitators is that they monitor three things: energy, rhythm and objective of the room. The same can hold true for panel moderators (aha!)

  • Energy in the room: Everyone is engaged, participating and making constant progress toward accomplishing objectives. (For panels: Keep the audience engaged)
  • Rhythm of dialogue: The dialogue flows, but stays focused on the initial goal of the meeting. (For panels: Make sure energy does not get broken by unrelated, fragmented questions)
  • Objective of the room: Make sure the meeting stays on track and accomplishes its objective. This can be tricky since the facilitator needs to balance discussion on side topics that are helpful to the objective versus topics that derail the goal.(For panels: Make sure the questions address a common theme)

I think there would be huge value in using these fundamentals when moderating a panel discussion.

When did you last attend a panel that really impressed you and what was so unique about it?

What are your thoughts about changing the dynamic of a panel presentation?

You can find more details on facilitation best practices in my past blog posts here:

They are some of the fundamentals that I present in my regular class on Facilitation Best Practices.

The Requirements Session Has Started. Do You Know Where the Business People Are?

When it comes to software requirements definition, engage the business … early, often and methodically

ClassroomLast week, I shared the results of a recent survey taken at a IT trade conference on the role of business in driving software requirements. Most of the people taking the survey stated that they consistently struggle in two areas: Connecting with the business and managing requirements throughout the development cycle.  They also admitted that at least part of their requirements process is broken.

This week, I’ll provide some thoughts on how to pinpoint some of these broken processes.

 

About to Start Requirements? Read this First.

During the requirements phase of a project, expectations and confidence run high. However, this is also the phase where lack of best practices begins to undermine success and worst practices rise to the surface.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics. In his white paper, “Doing More with Less: Best Practices for Processes, People and Metrics” [PDF], Geneca Vice President and Managing Director, Bob Zimmerman, suggests asking the following questions to draw out areas in need improvement.

How do you work with the business?

  • Do all business stakeholders agree on the goals of the project?
  • Who owns defining requirements? Is this different from who owns “documenting” requirements?
  • How do you know when a particular part of a project is complete? How do you know when the overall project is complete? Does your team have this information and does it align with business objectives?
  • In general, after collecting requirements, are Change Requests introduced during the first 30% of the development lifecycle?

How do you track projects?

  • Do project status reports show progress in terms the business understands or is it in “IT speak” requiring translation for the business?
  • Is project success determined by being on budget? On schedule? Meeting the original business objectives and ROI? Which one?
  • Does your team use one internal project tracking report for status while the external report is different? Or is there a common report showing progress on the project?
  • Do business and IT team members typically have a consistent view on project status and health?

Are project roles and responsibilities clearly defined?

  • Is there a single person and role accountable for technical issues?
  • If you deliver a solution that works but is missing key features required by the business, is there a single individual and role that is accountable?
  • Are your project managers accountable for tracking progress and making project health visible? Are the responsibilities for this role consistent across all projects and project managers?

By answering these questions, you should be able to hone in on the areas of your requirements practices most likely to impact your ability to satisfy business expectations.

For successful requirements definition, the various players need to be involved in ways they might not have been before. If the business is not 100% committed to making this happen, even the most talented development teams cannot predictably give the business what it needs.

Organizations that hold the business stakeholders accountable to define their needs enjoy better results. These teams do a better job eliminating guesswork and rework, supporting change control, improving testing efficiencies and, most importantly, delivering exactly what the business wants.

Business/IT Alignment: 4 Ways to Win Admiration and Respect

handshake-300x158Business/IT Alignment: How does an IT shop with talented individuals, the latest technology, millions of dollars in payroll, and a history of developing business centric applications become so disconnected from the business that they disappoint the very teams who depend on them? What can be done to close this gap and turn this relationship into a trusted partnership? While there are many ideas on how to address this difficult situation, in my experience there are three key approaches IT can use to rebuild burnt bridges and stop unconsciously undermining their business partner relationships.

Learn to speak a common language

In order for Business/IT alignment to occur, IT must adopt the same terminology and language of its business users. (A claim is a claim – not a bill or a statement). IT also needs to be aware that a complex project plan does not communicate meaningful information to the business. Deliverables need to demonstrate real business functionality, QA-passed and ready for review. The more often progress is shown the more involved your business partner gets. If communication is the basis of a good partnership, then a common view of success is the necessary foundation for delivering on business expectations.

Create a common view of success

One of the most disruptive events we can have when working with a partner is discovering you’re not working towards the same goals. Both IT and the business problem owner must work together to establish common success criteria for a project and eliminate assumptions.

Creating a common vision is a process that includes the problem statement down to a detailed description of the individual items to be produced for the solution. In many cases lengthy documents and general conversations are not enough. Pictures are worth a thousand words when developing product descriptions … even for the “simple” reports.

Spending time to develop the detailed components of a solution requires a time commitment from your business partner to get involved. This is the only way to reduce surprises that lead to project disappointment and rework in the development phases. The common view of success needs to capture the results of this cooperative effort in a manner comprehensive enough to help determine project scope, sizing and estimating. Once this process is perfected, it can be accomplished in as little as three weeks for projects up to a year in length.

Allow your business partner to manage change

In order for the project plan to not interfere with business decisions, individual items in the plan must include all costs and efforts. This gives the business the ability to effectively react to change and unexpected events. For example, if three months into a project a business is acquired or sold, the business partner should be able to easily substitute new objectives with the same cost and effort for the original ones.

Negotiate the plan with your business partner. Once the time and effort required to deliver each scenario is understood, the option to manipulate plan elements like building blocks allows the business to determine priorities and set the scope for the project.

Be open and demonstrate your integrity

No Business/IT partnership can survive ongoing disruptive surprises. Rather than trying to make up for problems or delays, communicate them and share options to schedule, resource or scope issues when they happen.

If accurate sizing and estimating best practices are not in place and original estimations are incorrect, IT needs to inform the business as soon as possible and reforecast the release plan. IT cannot afford to jeopardize its ability to deliver business value by hiding information or trying to take drastic measures to make up for project execution problems.

Utilizing these practices can help IT predictably deliver measurable business value and help make Business/IT alignment a reality. While this is not something done overnight, your commitment to building a true partnership with your business partners will go a long way in bringing predictability to a process plagued with missed expectations and cost overruns.

What practices have worked best for you to to enhance your relationship with the business?

feature photo credit: dotbenjamin
post photo credit: Aidan Jones

Beyond Complete: Success is Making a Lasting Positive Impact

What is “success” to you? Imagine yourself working on a project. The project is on-time and on-budget. All of the requirements have been met. But, how successful have you been with the project? Have you made a lasting impact with your customers? Are they eager to work with you on the next project? Are they recommending your work to others?

Reaching the Destination May Require an Unexpected Route

A customer engagement is not just about meeting the common standard measurements of success (on-time, on-budget, etc.), but is about partnering with your customers to predictably deliver what is needed for them to be successful in their business. It is about anticipating what the customer needs. It is about the courage to deliver a difficult message when you discover that the recommended solution is not going to deliver the desired results, even if you fear that you’ll be perceived as having made a mistake. And, it is about being flexible in your approach so you resolve issues instead of worrying about meeting a plan that you know is not working.

One of the most successful projects that I’ve worked on was neither “on-time” nor “on-budget” and the final delivered solution was significantly different than what was requested in the original requirements. Yet, the project was considered a success – the customer was extremely happy with the results and continued to engage with my company and team for additional work.

127385974_4c9b5e3acf_mFulfilling a True Need

What made this project successful?  Our team partnered with the customer to understand what the true needs of the project were. In the middle of the project, we determined that while we could deliver to the original commitments, the solution that the customer would have received would not have met the customer’s needs. Instead of continuing to deliver to the flawed plan, the team alerted the customer to the issues and worked with them to restructure the plan to deliver a solution that better met their needs.

Was the re-planning painful? Of course it was. As more information was uncovered, we actually restructured the project and the sub-teams twice during the project life cycle. So, in addition to keeping the client satisfied, there were also challenges in keeping the team focused and delivering quality. However, the end result was worth the pain in the middle of the project. The final solution delivered the value that the customer needed within the necessary time frame. The team was able to celebrate a successful delivery.

If we had stuck to the original plan, the team could have delivered the project on-time and on-budget. We would have met all the requirements of the project. It is even possible that we could have gotten future work from the customer. However, the customer’s perception of us would have been just another consulting company that they could use for work if needed.

Instead, by not delivering on-time or on-budget, but by predictably delivering value with “no surprises”, we became a trusted advisor to our customer and they became enthusiastic advocates of our company and our people.

What does “no surprises” mean to you? When have you changed the course resulting in a win for all?

Photo Credit: Olivier Bareau