Subscribe via RSS Feed

Category: Business-IT Alignment

Stay Inside the Lines to Manage Projects Effectively

Throughout the Getting Predictable blog, I talk about alignment. For many, the word “alignment” is a bit vague. Does it mean we agree? Does it mean I actively support you? If I don’t actively support you, but I don’t block you either, am I “aligned” with you?

As it relates to projects, doesn’t alignment simply mean we agree on what is in scope? Why are there so many books written on alignment, and why do they sound like “consultant speak?”

alignment

The cost of mis-alignment

Alignment is important because when a project team is not aligned, it can not only derail a project, but, in a very subtle manner, prevent the project from ever getting back on the rails.

Sometimes, keeping projects inside the lines can be challenging. In fact, it can be a lot like looking at a roadmap when you’re lost. You’re the driver, you have a navigator next to you, and GPS, and each one is doing something different. You’re not in sync, and it’s difficult to figure out where you’re going. In the confusion, you end up getting even more lost, and it takes you twice as long to get to your destination.

This example illustrates how bad alignment can steer a project – or a car trip – right off of a cliff. The concept of alignment is often a bit of a no man’s land – people don’t understand just how harmful bad alignment can be to a project.

Silence is not agreement; Don’t let others hold their breath

speakup2It’s not often, but I believe we have all experienced the meeting that goes too smoothly.

There’s anywhere from four to eight people, trapped with each other for an hour, around our favorite conference table.

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.

Announce Changes and Avoid Wig-Outs

breaking pencilIn previous posts, I have discussed best practices around Change Control. Or, maybe I should say “lack of best practices” since so many organizations either fail to follow a defined process or simply don’t have one.

Eliminating the “Black Box Effect”

Eliminating-the-black-box1Regardless of whether you are doing iterative development or use waterfall methods, you may be struggling to get agreement on whether a delivery team is on track or falling off expectations. This blog covers techniques that can help business and technology teams agree on how to track progress of a technology project.

The Black Box: is any comparatively small, usually black, box containing a secret, mysterious, or complex mechanical or electronic device.

One of the key complaints of a pure waterfall development approach is the reality that a project may not show any results (or provide any feedback) until the software is completely finished.  In other words, the business really has no idea if the project will meet their needs or is on schedule until the software is delivered.

For example, we start a project in January.  It may take through February for initial business architecture and design to be completed.  It may take another month or two before software is actually being developed and delivered to the testing team.

The business may not get any visibility into working software for six months or more.

This is what I call the Black Box Effect. We need to find a way to eliminate this effect and have an agreed upon approach to determine whether a project is on track or not.

The benefits of an iterative approach

There are many reasons an organization may choose to move to an iterative development model such as Agile or Scrum.  One of the more important reasons is to gain more frequent feedback on whether what we are building meets the real business need.

Are you  tired of the business saying, “What did you do to me? I thought we were going to have this done.” And are you tired of hearing yourself say, “Well, I thought we were going to have THIS done!” If that’s the case, then you are obviously not in agreement and have a “visibility” problem.

Visibility isn’t a project plan!

Visibility isn’t a project plan that tracks progress. Visibility is agreeing that the business can get access to completed functionality. Visibility means the business can see how the software being developed will help them achieve their business objectives defined earlier in the process. If they can get visibility into that on a regular basis, then we can agree on whether we will be able to “high-five when the project is done.”

Not only do we need to provide the business visibility on progress, but we need to allow the business to re-evaluate their priorities based on the progress seen. Consider this a feedback loop, allowing development teams to constantly re-evaluate and tune their approach.

I use three key opportunities to provide visibility and get feedback from the business: QuickPeek, Showcase and Release.

QuickPeek

At the end of each iteration, the team should be able to show software that has been developed and completed through unit-testing. The software may not have been put through functional testing or even integration testing, but it has been completely unit tested. There may still be remaining defects.

We encourage the business to review each iteration’s results and make sure we are on track with their expectations – even if the code is not yet packaged for deployment or completely system tested. Remember, the QuickPeek  is typically informal and just to show the iteration progress.

Even in a Waterfall process, you should be able to start identifying key components being developed every two weeks that can be “viewed” by a business stakeholder for feedback.  Maybe some deliverables will take a week while others take up to three weeks.

I believe you can introduce a QuickPeek on a regular basis without too much intrusion into your current corporate process.

Showcase

When a release is going to take six or more months, there is value in planning a Showcase.  This  is a formal review of a set of features or system components.  Functional testing is typically complete and it shows complete business scenarios or processes at work.

However, it typically is not ready to be deployed like a release.

The purpose of the Showcase is to demonstrate the functionality of a complete component to a wider group of stakeholders. It is also used to celebrate progress and create a common vision around the new solution.

Even in an Agile world, you may not be deploying a release until Iteration 10 or 12.  Therefore, there probably is value in creating a Showcase around Iteration 4 and Iteration 8 to provide greater visibility and market the progress you have made.

Eliminating the Black Box creates Visibility

I hope these techniques can help even a waterfall shop create greater visibility and market the progress the team is making. Throughout the development process, it allows the business and I.T. to develop a common view of progress and decide whether adjustments need to be made to the final product.

Do you incorporate all of these techniques? If not, what are the obstacles?

Alignment Through Visibility

Testing-Alignment-Through-VisibilityIn my last post, I described how a lack of true alignment could create rework for a team. Worse, a lack of alignment may be the root cause of projects that are over budget and behind schedule. So driving alignment isn’t just a nice “political” move, it actually is smart business for your organization.

Because alignment is so critical to project success, it’s important to know whether your stakeholders are truly in alignment or just appear to be aligned but are actually going in different directions. There’s an easy exercise you can use to verify true alignment or simple agreement. This exercise is based on the concept of visibility.

Before I explain this exercise, it’s important to understand the difference between visibility and transparency.

Visibility vs. Transparency

I recently had a great conversation with a colleague about the difference between visibility and transparency.

Transparency is a behavior that a team member exhibits. Leadership and stakeholders have full awareness of the team’s effort and progress because of the transparency provided by the team members. Although this is desirable, it may not provide the stakeholders visibility into the project’s future.

Visibility is the result of transparent behavior. If I have visibility, then I know what to expect in the future.

Verifying alignment through visibility

Here is a simple exercise demonstrating how you can use visibility to verify true alignment.

Lets pretend we have business stakeholders who have agreed to build a lightweight version of Microsoft Word for a mobile device.

Originally, one stakeholder, we’ll call him Michael, was concerned over the concept of “lightweight”. He believed that the version needed to be able to read any version of Word, including showing “markup” made by tracking changes. He also thought having a lightweight version of Excel released at the same time was important.

After much negotiation, the stakeholders agreed to deliver a lightweight version of Word. The technology team provided an estimate of five months for the initial working release.

To make sure everyone is on the same page, I might ask the technology team:

“Is it reasonable that within two months, we will have a prototype showing us the base app that can l open and save documents and do fundamental editing and formatting?

Would it also be reasonable that everything related to formatting, spellchecking, email integration is done by the third month?

Finally, is it reasonable that the app will be fairly complete by the end of the fourth month so we can run some quality testing? Will we be able to complete the final testing and defect fixes in the last few weeks?”

If everyone high-fives and agrees to these assumptions, then there is a high likelihood of true alignment. Everyone has clear visibility and common agreement on how we track progress to our agreed upon goals. On the other hand, if the stakeholders don’t have agreement on these assumptions, then odds are they’re not in alignment around the ultimate goals and definition of project success.

In summary:

  • Assume it’s about five months to deliver
  • By end of second month we will have initial preview of base app, file functions, core editing
  • By the end of the third month we will have spellchecking and email integration
  • By end of the fourth month we have the app fairly complete and can start testing, packaging up, etc.

However, what if the delivery team reacted differently:

They say that five months was heads down development time. The testing, packaging, and changes would be “added” to the end of the five month schedule, making it six or more months.

Then, the business stakeholders may ask: “When will I see the markup-review? Is that at the second or fourth month check-in?” Only by having clarity and a common understanding on the future visibility of the project, can we truly be on the same page and have true alignment.

A quick summary:

Another way to look at visibility: Let’s agree upon how we track expected progress. If we can’t agree on that, then we probably are NOT in alignment.

So what do you think?

Do you believe this is a problem in your world? How bad is it? I’d love to hear examples in the comments below. If you don’t have this problem, why? What do you believe you are doing right?

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

Alignment: Antidote to Rework

Alignment-Antidote-to-Rework1In my last post, I introduced the Getting Predictable℠ Best Practices and explained  how they are designed to set project teams up for success “from the start”.  These practices cover three areas: Alignment, Commitment and Visibility.

Now I am going to dive deeper into the  concept of alignment and why it is critical to reducing rework and helping any team (not just IT) meet its  expectations, each and every time.

What is Alignment?

With technology initiatives, the goal of best practices around alignment looks like this: The business stakeholders all have a common answer to the question, “What is success for this project”?  In other words, they have agreement when the team can stop and everyone can  high-five because they all got what they needed.

At the other extreme (and this is the problem we are trying to solve), we don’t want the business to say to the team: “We have a really critical schedule, so you guys start and we’ll figure it out later”.

Why is it so important to focus on aligning the business stakeholders?  Isn’t it more important to focus on aligning the technology team to the business? No it is not more important – and this answer is of huge importance!

The technology team can’t align to the business goals if the business doesn’t agree on those goals! In other words, if the business isn’t in alignment, how can a technology team align?

What are they aligning to?

More importantly, a lack of alignment on the business side means there is almost certainly rework ahead for the technology team.  As the business goes through the process of coming into alignment, the IT team needs to make constant adjustments.  Sometimes in small ways, but other times the change can be significant and involve removing or changing an entire component of the solution.

When was the last time rework got extra schedule or budget?

This blog will cover those Getting Predictable℠ Best Practices that focus on helping the business get alignment on answering this question:  “What is the definition of success for this project?”.

Alignment is a great idea, but I don’t think it can work for me

Now you  might be thinking: “I can’t get my business folks to a single meeting, let alone get them to agree!” In future posts, I will share best practices that have worked for me. They don’t all work, and they don’t apply to all situations, but I have come to rely on these simple practices to get the results I am looking for.

And there is a huge side benefit.  By helping the business come into alignment on the key objectives of a project, I end up building a new level of trust in my relationship with the business team.  This truly was a pleasant surprise.

You will find some past posts, as well as future posts that focus on key areas such as:

  • Facilitation techniques
  • Aligning the business when they are geographically distributed
  • How to align interested parties that aren’t decision makers
  • Being adaptive to change and protecting alignment
  • When a lack of alignment is ok

So what do you think?

Do you believe this is a problem in your world?  How bad is it? I’d love to hear examples in the comments below.  If you don’t have this problem, why?  What do you believe you are doing right?

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

Discovery: Going Where No Person Has Gone Before

Discovery-Going-Where-No-Person-Has-Gone-BeforeTypically, at the beginning of a project, we begin by collecting requirements from the business. We might spend a month or more gathering requirements. If we are using a more Agile approach, we may spend a few weeks gathering requirements for the first few iterations in the form of stories.

Every once in a while, I find myself starting a project where  for every step  forward we seem to be taking two steps backwards (or at least sideways).  Let me explain: As soon as the development team starts to code, literally within the first week or two of coding, the change-requests start. Does this mean the business is already changing their mind? We are just beginning to code!

So how is it that the business is changing their needs within weeks of starting a project? I can see change requests occurring once they see some initial software delivered.  But why do we regularly see projects with  change requests before the business even sees a deliverable?

We might assume that we had the wrong stakeholders in the room.  Another potential cause could be that we didn’t do a great job collecting requirements. Certainly, there are projects where one or both of these problems exist.

But what I often find  is that the project is suffering from a case of “Discovery”.  More specifically, the business is stuck in Discovery and is not ready for Definition.

Discovery vs. Definition

Let me contrast the difference between Discovery and Definition. Put simply:

Discovery is the phase where the business identifies what problem to solve as well as a description of the end-state or goal of the project.

If Discovery defines what problem to solve, then Definition defines the path to the solution. In other words, the Definition phase focuses on how we are going to achieve the end goal.

An Example:

A small company is in growth mode, doing very well. At a recent Board-of-Directors meeting, the company’s management team was asked how they can continue their revenue growth over the next two or three years.

They currently develop advanced Word Processing solutions for Android products. Their solutions are customized to that platform and to take advantage of all the Google Android features, giving a rich experience on a mobile platform.

To increase revenue, they can choose to develop a complimentary Spreadsheet tool for the Android platform, providing the same, rich user experience and Google feature integration.  On the other hand, they can choose to create an identical Word Processor and user experience on other mobile platforms such as iPhone and Blackberry mobile devices.

There are probably other paths as well, all providing a path to their continuous revenue growth. At this point, we are “Taking a single goal and generating multiple ideas.”

Moving from Discovery to Definition

After much research and due-diligence, you conclude that the best direction would be to offer your current Word Processor and all of it’s rich user experiences on the iPhone and Blackberry platforms, solidifying your brand as “The Mobile Word Processor. Period.”

At this point, we have completed the Discovery phase because a decision was made on the overall goal. Now, it’s time for Definition.

In Definition, we  begin to define the path to that goal.  We start to define the key features that MUST be in the iPhone version and how we will replace Google Android features within the Apple iPhone environment.

Clearly identifying this  feature list is what is called Definition.

So Why Should We Care?

If you are trying to define the requirements for a solution, but your business stakeholders are still discovering what they call success, then you are destined for rework! And this will show up as:

  • A proliferation of change requests early and often
  • Slipped schedules, since they didn’t anticipate these discovery changing goals
  • Budgets being blown since they didn’t anticipate the increased costs associated with rework

Because they are still in Discovery, we can’t be sure of the right direction. Any step we take could cause rework that translates into budget and schedule variances.

My guess is that you could think of a project or two right now where the business stakeholders were probably not ready to define their system. And, most likely,  this “re-thinking” of their projects goals created a great deal of pain for everyone involved.

So What To Do?

When you are collecting requirements, or engaging with the business, if you believe they are not ready to define how the system will work, you need to “pop-a-level”.  I use this term when I want folks to take a step back, and take a different view.

So if you suspect you are being setup for a great deal of rework, then pop-a-level and ask your business team:

  • Do you have the right Subject Matter Experts who are knowledgeable and empowered to help define your needs?
  • Are you  still in Discovery? Are you unsure of what a clear definition of success is?

In either case, try to create transparency around the issue, highlighting the potential costs of continuing to move forward when the wrong stakeholders are involved or the goals are fuzzy.

Realizing your project is in Discovery is half the battle. No matter what’s ahead, this realization will enable to you stay on course and manage the project more effectively.

Have you experienced Discovery? Please share your experiences in the comment area below.

Are You Holding Back Your Team’s Success?

Damaged WallRecently, I hooked up with a friend and decided to do a 3-day hike on the Appalachian Trail.  As part of our preparation, we decided to try a day-hike in a State Park near our homes. We took this trial quite seriously and even planned how to mentally and physically prepare for the day hike.  I won’t bore you with the details, but the day we set out for the hike, we were pretty psyched.

We did 8+ hours on the trail, walking up and down paths that burned our legs by the end of the day. In the last hour or so, when were truly coming to our “wall of tolerance”, we kept repeating to each other how fortunate we were for all the planning. Had we not trained for this or lacked  the right supplies, we would have never lasted the day. Without a doubt, doing the day hike before setting out on our 3-day hike out east was the smart thing to do.

We focused on setting ourselves up for success.  And even with all the planning, we still learned a lot about what to do differently on our next day hike.

Learning From the Hike…

I can only imagine how painful that day would have been if we didn’t work our way up to walking an entire day of 13+ miles.  Or what would have happened  if we only had half our water ration (we used it all).  It would have been one embarrassing, failure of a hike.

This is a far more common scenario than any of us realize. When we start a new project, we typically overlook fundamental / key things that would set us up for success.  We may actually be holding our team back from the start.  And because of that, our team  may be digging out from this “team debt” for the majority, if not all, of the project.

Hold Up There

If you don’t agree, let me  give you just two common scenarios  that prove my point:

  • You  are starting a project. The  team is staffed and eager to move forward. The technical team is building out the environment and frameworks.  The Business Analysts are ready to collect and refine requirements, but are struggling to get the needed time and commitment from the business.

This not only causes churn for the BAs, but typically squeezes the schedule during the initial coding activities, with incomplete requirements and test plans.

  • Another example: You  are staffing up a project quickly so you can hit a set of aggressive dates for the business.  In doing so, you need to procure development environments and machines for all of the developers. However, due to an overworked infrastructure team, or worse, due to corporate processes, a third of the team may be without development hardware and tools while they wait for their stuff.

While they find other activities to do while they wait, this literally amounts to two or three weeks that could have been spent on actual deliverables.

These are just two common examples. You could probably start listing off a couple more.

What Are They Thinking?

So when this happens, what is management thinking? Are they intentionally setting a team up with an obstacle? Do they simply not care and assume we can adapt?

I believe that in most cases, management simply doesn’t realize that the team is being put into this position and the cost is more than a slow ramp-up to the project. I, myself, have asked teams to “see if they could work around some obstacles”, clearly not realizing the pain I may be introducing, not just short term, but to the long term success of the team.

So What Are We To Do?

I think one of the most basic things we can do in these situations, is to be vocal.  Share your clear and honest explanation of what the cost and impact is.  It is important to be accurate and not embellish or magnify the challenges.

For example, let’s say you have a project starting and are scheduled to collect requirements for the first deliverables during the week of 11/01.  Your  goal is to have the requirements and test plans completed by 11/15 so the developers can begin development.

If the business stakeholders are not available as needed the week of 11/01, I think it’s important to point out that development may not start until 11/22.  This is because the test plans won’t be complete and the requirements won’t be clear enough (the normal clarification won’t have happened).

If you can clearly show the cause and effect, management should take ownership of the cost and impact of these situations. If we can show them the cost in terms of dollars or in terms of schedule, then you have the best shot of setting your team up for success and getting management to own the challenges.

What do you think?  Have you found other approaches to help set teams up for success?

IT as Great Facilitators Part 4

What Great Facilitators Know About Estimating

IT-Great-Facilitator-4Last post, I shared an exercise that helped teams understand how to develop a plan that is manageable and achievable. I call this “Commitment Based Estimation”.  Now, I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to be effective at facilitating estimation sessions,  I’m going to discuss how to select the best person to facilitate these sessions.

I typically find that the team-lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who can allow the team to own the estimate.

When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to constantly optimize an estimate, then the team won’t feel ownership. This is not how to get a Commitment Based Estimate.

Similarly, when an architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.

Now, you may be thinking: Does this mean I can never challenge a team? It does not. What is does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.

For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now, you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Good Facilitators Can Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic.  I talked about this in a past blog called “Attitude of Estimation”.  As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered.  Project Managers can offer perspective on dependencies and resource availability.  The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects, and the database team also need to weigh in.  Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

Have you ever been in an estimation session where the facilitator was more of a hindrance than a help?

I hope you have enjoyed my 4-part series on facilitation. If you missed them, here are the links:
IT as Great Facilitators Part 1
IT as Great Facilitators Part 2
IT as Great Facilitators Part 3

In my opinion, there are way too many people who take the facilitator role for granted.

I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them.  A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.