Subscribe via RSS Feed

Tag: "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.

Delivering Successfully is like the Matrix: It’s All In Your Head

matrix-300x269

In this blog I usually  write about best practices that help set teams up for success. That is really what Getting Predictable is about.

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.

Why Your Change Request Estimates May Be Out Of This World!

PenetrationIn my last post, I talked about why it is critical to have different roles involved in the Change Control process. Failure to include a larger team in change assessment is a common oversight that makes it harder to understand the total impact of a change request.

Staying with the Change Control theme, I see one other challenge that occurs across teams. It may not occur “every time”, but when it does, your estimate for a given change request may be off by orders of magnitude.

 

A typical approach to estimating change requests…

 

When developers receive change requests to estimate, they start by understanding

  • the current functionality that exists,
  • the desired change to this current functionality,
  • the impact of the change and effort to complete the change.

While I know this is over-simplified and obvious, I want to drive into the 3rd bullet, assessing the impact of the change request. I believe most individuals assessing changes do a fairly complete job in assessing the impact. But there is a hidden monster (or pothole) that can destroy the accuracy of an estimate.

Let me illustrate with a quick (and over-simplified) example. I’ll call it …

The Grid

Let’s say your application includes a search screen that allows a user to search through all of the employees in your company.  The search allows you to search for employees by office, region, tenure, etc.

A change request comes through that says they want to be able to hover the mouse over any employee record in the result and display the details in a pop-up bubble.

With a  mock-up of the bubble and a clear understanding of the data, the request seems simple enough.

You estimate the impact of adding this functionality directly to this search might be one to two  days to complete and have ready for business review.

 

 

 

 

Enter the hidden Reuse monster

As it happens, the employee search in this system is reused in several different areas.  One of the areas is the ability for any employee or internal contractor to search for an  employee’s name, office and phone extension.  Because it isn’t obvious that this search is reused when first looking at the code,  you may inadvertently add this functionality to all the areas where  a user  can search for employees!

But WAIT! Do you really want just anyone getting personal details of your employees? You probably only wanted the management group to have this access, right?  So when you add this functionality, you now have either created defects in other areas or  have to “break” the reuse and write this code separately.

For all my architect friends out there, yes there are better solutions to solving this problem. But here is my point:

Many times when estimating what implementing a change would take, we don’t verify that the code involved in the request is not reused elsewhere or that other dependencies exist.

We may do this when making the change, but we need to know this when estimating the change too!

It may impact our own estimate as well as the QA estimate for this change request.

So here’s the quick tip

When estimating for a change request, make sure you estimate the impact this change will have on functional or code reuse. It isn’t always obvious!

Can you think of any recent examples when your change request estimates were out of this world?

Change Control: Do You Own It or Does It Own You?

Change-ControlOver the last year, I have noticed a myriad of projects that begin to struggle once they begin the change control process. Doesn’t matter the type or size of project – they all appear to drop-the-ball when it comes to following the change control process. This pain surfaces not only in the schedule and budgets, but also in the lack of trust that builds between the business and technology teams.

I want to share some best practices than can help teams manage change control in a more disciplined format. In this first post, I discuss the key roles that should be involved in change control.

What is the typical change control process?

In a typical scenario, the business or project stakeholder comes to the table and says they want to change some functionality. This can be a change to something already built, or it could be a change to some requirements you have collected but haven’t implemented.

When asking for the change, the stakeholders typically want to understand any impact to cost or schedule before committing and asking you to “implement” or “deliver” the change.

What are the roles typically involved in change control?

In a typical change control process, the roles look something like this:

After a change request is submitted, someone is responsible for tracking and reviewing (think triage here) the change request. Acting as an editor, they review the change request and make sure the request is complete and without ambiguities. If there are any gaps or missing information, they go back to the “requester” or to the stakeholders to get the missing information. Obviously that’s pretty standard practice.

Next, one of the technology team members needs to assess the change request and determine what, if any, impact it will have on the current plans. By assessing, I mean sitting down and evaluating the impact of this change request against schedule, budget and staff. They may also identify questions for the stakeholders that need to be answered before they can complete their assessment.

This is where you typically have a “go to person” to do this initial assessing. This resource will typically be asking questions like:

  • Are we short on staff to handle this request?
  • What impact will there be to schedule?
  • What additional risk and/or dependencies does this add to our project?
  • Do I need any “specialists” or unique tools for this request?
  • And so on

The Changing Roles of Change Control

This is where I suggest including a larger team to do the change evaluation. Many of you may already use this approach. Kudos!

But for the rest of us, I suggest that we get a total view when assessing the impact of a change request. This means include a business analyst, quality analyst, etc. in the assessment.  I know there are some Agile teams that do this with all team members. Woohoo!

Why is this so important? Because one person probably can’t truly know the impact this change will have on other parts of the development or the development process.

For example the change may be trivial for the developer because it will take just two hours effort. However, the Quality Assurance team may have to rerun all of the regression tests, impacting the schedule by up to two days. A business analyst may actually look at the change and say, “Given the change, do we need to change three other things in the system so they’re all behaving consistently?” All of a sudden, the business analyst may have to modify other requirements. The dominoes may begin to tumble.

I suggest you make sure all roles on your team are included. It would be sufficient if a single team member plays multiple roles as long as this person knows they’re representing these other roles and thinks through the implication to other scheduling, staffing and costs.

Communicating Change

Make sure change requests are communicated across the entire team. Communication to and within the team is a discipline. Some of my experiences this year have reinforced that communicating changes isn’t optional.

Many team members think a trivial change (like a cosmetic change) doesn’t require informing the entire team. Again, this is NOT optional. It must be understood that we as a team are committed to each other and we’re not going to ”surprise” each other with changes requests. Once that is established, we need to educate the business, clients, and  stakeholders about our change control process and that they, too, must follow it.

Three Key Take-Aways:

  • If you don’t have a change control process, implement one quickly.
  • If you have one, but you’re not using the discipline to enforce it every single time a change comes through, you need to introduce that discipline to the team.
  • If you have a process and discipline, make sure that when you do the assessment all the roles are included (even if it’s one person representing the roles). Reinforce that the efforts of the QA, BA, etc.  have to be taken into consideration.

Do you have any other key best-practices for handling change control?

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.