Subscribe via RSS Feed

Tag: "project success"

How to Avoid Being Stalked By Scope Creep: The Project Charter

scope-300Scope Creep. Sometimes it’s politically motivated. Sometimes it’s intentional. Sometimes it’s a misunderstanding. But it’s always painful.

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.

What Taking-a-Hike Can Teach Us About Business

Hiking in autumn forestSomething Special…

This week I have something special for you. A guest post from one of my best friends. Dave Katauskas regularly shares insights that  make a huge impact on a team’s performance and success.  The story below has changed how he and I make choices within our daily work.

So, without further ado, I hope you enjoy the following blog post as much as I did.

Have I got a story for you!

Recently, my friend, we’ll call him “Bob”, and I decided to hike on the Ice Age Trail in Wisconsin. This was in preparation for our bucket-list-goal of walking a portion of the Appalachian Trail.  We knew any hike would be a challenge merely because we were non-active desk jockeys, 50+ pounds overweight and past middle-aged.  If you’ve ever seen the “before and after” photos in most health diets, we would be in the “before” picture.  I believe that sums it up.  Yet, we were determined and eager to get started.

Let’s get going!

On the first day of our 2-day hike, we set out on the Ice Age Trail to explore the wilderness and just enjoy ourselves.  We saw many great sights and regularly rested with food and water from our backpacks.  It was a great day with perfect weather.  All of the elements indicated that this day would run flawlessly.  In an eerie sort of way, this was strangely similar to the optimism and energy we have when starting a new and exciting project.

Knowing that this first leg of the hike was only a day hike, at some point in our journey we would need to turn around and track back to our car.  The morning went well. We felt strong, full of energy, sharing a great time on a beautiful day. The morning was going quickly and before we knew it, we reached the five mile mark. It was just after lunch that we started to think that turning back at this point would be smart. The second half of the hike would probably go slower.

After looking at the map, there was a ridge ahead that would provide some interesting views and a shelter.  Feeling physically able and still eager, I suggested that we squeeze in a few more miles before turning back.  Bob had a gut feeling that we needed to turn back because we may be reaching our physical limits.  He’s older and more out of shape. Of course, he was also being risk adverse. We all have a Bob on our project!

We clearly weren’t in agreement, so we discussed it a bit.  But without the definitive proof that we were actually reaching our limit, we decided to press on. His version of this story is that I convinced him to press on. We agreed to turn back at mile seven.

Around mile six, the path changed to a steep incline. I mean a painful, slow, incline.  But we made it to the top and to mile seven.  We felt great at arriving at the top of the ridge and rested on the trail near the tall grass.  Unfortunately, the view wasn’t as spectacular as we had imagined.  In fact, there was no view at all except for tall brush and grass.  But we still felt great at making it to mile seven!

So we took a break and decided that it was time to turn back.  The first seven miles were great so the next seven should be equally great…right?  As you’ll read later, we were oblivious to the fact that we were just short from the real “point of no return”.

It’s really not that much farther…

Well, about two miles into the return trek, we realized that we were out of water.  In addition to that, our legs and feet were starting to become very fatigued and sore.  But press on we did, not that we really had an option.  So, another two miles later (that’s 11 miles total for the geeks doing the math…like I just did) we were now becoming worn out. The storm clouds started rolling in, the wind was picking up and our flawless day was no longer looking so flawless.  We now had as additional sense of urgency to stay out of the impending storm.  Yet, we still had about three miles to go.  We saw the coming gloom, we still had plenty of trails in front of us and we were in pain. Talk about a “Death March”! (Have you ever experienced a software project similar to this?  Doesn’t this really sound like the beginning of a death march?)

Houston, we have a problem

The next mile became a struggle as our bodies were not actually equipped to deal with the demands which we had placed upon them.  This next mile was truly indicative of what the final two miles had in store of us.  Our legs started cramping, each step was actually painful and we were thirsty.  We limped along, well aware of each and every step. We genuinely weren’t sure if we would make it back to the car without some assistance.  (How many times have we committed to more than we can successfully handle?  Or actually know what we are really committing to?  On the plus side, we did know that were very close to needing to ask for help.)

And then it happened…

It became apparent to us that our short term view of what we thought was feasible became a decision that ultimately created pain, anxiety and the possibility of failure.  To add insult to injury, it started raining. (The “death march” continues)

After a long while, we finally reached our destination and found a covered bench.  We sat for a few minutes, then headed toward the car; a distant 12 feet away.  Limping and cramping is what I remember mostly.  After what seemed like an eternity, we walked from the bench to the car.  Now we just needed to get in.  We somehow managed to hold back the man-tears. Well, at least I did!

The residual evidence was apparent by our pampered and ginger walking around the office over several days.  A trip we’ll never forget!  (I’ve certainly been on projects where we limped across the finish line). Yes, pain is certainly one of the best teachers.

How we changed our views

A few weeks after our hiking experience, we were able to reflect again upon our journey and we noticed similarities around how making decisions for short term goals, or decisions based on lack of insight, can have significant effects on long term outcomes.  The decision to continue after mile five was clearly a bad decision.  We talked about the moment, that specific choice, which led us to continue on.

Then I thought about all of the bad decisions that I’ve witnessed and made on project work. But instead of the conversations centering on making a bad decision, we would state that it was just poorly executed. We would never challenge our decision approach or conclusion.  For this hike, our execution was fine; the decision was bad.

We then started discussing some of the decisions that we’ve personally made in directing business objectives and how some of those decisions created pain for ourselves and others.  And, in some cases, it established additional barriers for corrective action.

Our take away…

So, when making business decisions today, I now ask “how can we prevent this from becoming our 14 mile death march?” and “are we just kidding ourselves?”  I was actually able to put this into practice one day when our leadership group was discussing strategic staffing.

We knew that a decision to handle a short-term, non-bulls-eye opportunity would certainly hurt our capability to engage in an on-target opportunity in the future.  So, we had good discussions around that topic and looked at the varied perspectives with our eyes wide open.  We stuck with the strategic goals in spite of a small immediate win.  And since then, we’ve been able to apply that same concept to other growth challenges.

In addition to all of that, Bob and I have since hiked again.  This time, it included a change in our behavior, thinking and knowing our real capabilities.  It was a more pleasant experience.

So next time you have a tough choice and everyone is debating an approach, consider you may be at mile five of your hike, and sometimes, it’s better not to push the limits … because you’ll feel the pain for quite some time afterwards!

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.

The Role Call: A New Practice to Set Your Team Up for Success

The-Role-Call-ChecklistLast post I wrote about how often we begin a project from a disadvantage right from the start. Usually it’s because the team doesn’t have the resources or the commitments it needs from outside of the team.

In this post, I want to talk about a new best practice I am experimenting with. This practice is  designed to help set teams up for success by focusing on the project team resources. I call this best practice: The Role Call Checklist.

Key Roles On a Project

First I need to  explain the common thinking on key project roles: Specifically, every project is made up of 4 key roles. In no particular order, these roles are:

  • The Architect: This is the person responsible for the technical solution. For example, “does it work or do you get 404 or blue screens of pain”?

 

If the final application doesn’t technically work, or if it doesn’t meet a non-functional requirement, such as scale, then the Architect is accountable. I am not going to follow up with the Project Manager. It’s the Architect’s responsibility.

  • The Senior Business Analyst: This role is about  understanding what business problem this project addresses and, from a business point of view, what is success. Business Analysts are the proxy for our business users.

 

If the final solution works technically, but doesn’t do what the business needs, and doesn’t allow the business to achieve their goals, then the Senior Business Analyst is responsible.

  • The Senior Quality Analyst: QAs are responsible for the quality of the solution. Before everyone jumps on me, I don’t want to get into the discussion of exactly what the QA role is and how encompassing it is. I am a true believer that the QA role is larger than a testing organization. Their job is not to simply test and place a sticker on the software saying “Inspected by #12”.

But for this post, I hold the Senior Quality Analyst accountable to identify what quality the system holds.  What are the defects and is the system compliant with the intent? If the system technically works, and if it was designed to meet the business needs, then the Senior Quality Analyst is accountable to say whether it is ready to ship.

Finally,

  • The Project Manager: The PM is responsible for overall transparency.  This person needs to have an accurate picture of where we are in relation to schedule, budget and meeting Business Objectives. Further, they are accountable to serve the team by helping to identify and, more importantly, facilitate removing obstacles that can prevent the team from being successful. They are the manager.

Although I believe every project, small or large, has the need for these four roles, they don’t necessarily need to be four separate individuals. On smaller projects, you may have a single individual playing the Project Manager and Business Analyst role.  Or you may have the Business Analyst playing a Quality Analyst role. It depends on your culture and the strengths of your team members.

But the need to define:

–        What you are building,

–        How you are building it,

–        Whether you built it properly, and

–        How you’re managing the process

is required on every project. When a smaller team doesn’t believe they need each of these roles, it can create a gap to successfully delivering a solution.

And this brings me to the new best practice I am experimenting with:

The Role Call Checklist

I create a mini-checklist for each these roles. Under each role, I write what the role is accountable for. While there probably will be a common list of  responsibilities across many of our checklists, each role will also have some unique views.

If you are assigned a new project, I recommend creating this checklist to determine who is playing each of these roles.  On a smaller project, you may have one person playing two or three roles.  On a larger project, you’ll want to  identify the key owner of each role.

Then, I recommend that you meet with your team and make sure you are all in agreement as to who is doing what, and what the team is relying on each person for. I believe this small exercise can help a team start more successfully, especially when resources are scarce.

If you have a checklist, I would love to hear from you and find out what works and what doesn’t.  Does it make a difference?  Are you willing to share yours?  Feel free to add a comment 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?

Is Your Software Development Team Set Up for Failure?

Obstacle - Man Jumping Over Word on ArrowI talk to CIOs all the time and I can tell you that there is one common concern keeping them up at night:  Am I getting the best RPM out of my team? Often the answer is no.

Unfortunately, many of the teams I’ve worked with are continually frustrated because they truly, legitimately feel they are being set up for failure. They’re tired of being told they’re late, spending too much money, or missing the boat when it comes to getting the business want it really needs.

Throughout my career, I’ve heard this question from my peers, direct reports and senior executives:  Who or what can we change to fix our team? If these concerns are on your mind, I highly recommend taking a look at my white paper: “Doing More with Less – Best Practices for Processes, People and Metrics.”

This whitepaper will help you identify opportunities for optimization based on your specific organization, business situation and culture. Some of the concerns I address:

  • Is your methodology getting predictable, repeatable results?
  • Do you have legacy practices and tools that actually hinder performance?
  • Are the right “heads” in the right “hats”?
  • Is everyone on the same page as to who owns the success criteria for projects?
  • Are you tracking the things that make a difference to the business?
  • Are metrics visible and “common” across IT and business?

This white paper will get you started in one of the most critical roles you have: Removing obstacles.  If you don’t support your team in removing the obstacles that prevent it from delivering, you are setting your team up for inefficient and unpredictable results.

Please take a look at this white paper as soon as you can and feel free to post your comments right here.

Geneca Whitepaper – Doing More with Less