Tag: "business"

You Guys Start, We’ll Figure This Out Later

We’ve all experienced a project that is kicked off just a bit sooner than maybe it should. You know this because you hear those infamous words:

“You Guys Start,
We’ll Figure This Out Later.”

Consider this simple phrase a warning sign that your project is in danger before you even start. The business team is still trying to figure out what they need. Yeah, they know their problem is clear but the solution is anything but.

So what’s behind this all too familiar call for help?
Lack of Alignment.

What the business is really saying:

“You Guys Start and We’ll Get Aligned. Right Now We Can’t Agree.”

This lack of alignment is almost always due to the business stakeholders’ struggling to determine and agree on what “success” is. This can apply to a product implementation, customer software development or even a change in business processes.

Some disagreements can be on the large scale:

Should our first release of tax planning software only focus on Federal tax strategies or must it support State tax planning too? If it should, which State? All 50? Isn’t that going to take forever?

Should we develop a full suite of open source Office type products including a word processor, spreadsheet, Powerpoint like tool? Or should we simply focus on our core offering, the presentation tools?

Some disagreements appear less strategic:

Does the solution have to support our customers in four countries and be localized in six languages? Or can the first release simply support our current client base?

Should our solution include a Spellchecker for the medical terms that we will collect in our survey tool?

“You Guys Start, We’ll Figure This Out Later” = Less Than Successful Project

In spite of this warning, the project needs to start. So we begin our planning and whenever possible, hedge our design to accommodate change. But, in the end, how likely is it that we deliver what they, the un-aligned business stakeholders, fuzzily define as success?

More often than not, they never get aligned. And if a new business person gets involved, who knows what their view of success is. At the end of the day, we are responsible for a potential “less than successful project”. Hmmm – they may even call it a failure!

And this shouldn’t surprise us! In fact, if you hear the words “You guys start…”, that should be a predictive flag that you may be setup for failure.

The message is clear: The Business needs to own the risk of having an I.T. team start without alignment among the Business. And the Business along with I.T., needs to jointly own and collaborate on how I.T. will re-plan once the business has completed their work by finally agreeing on what is project “success”.

What About Agile?

When I share these ideas with colleagues, I typically get two reactions. The first includes smirks and smiles saying: “Yep – we’ve heard that and you are right, it is painful.”

The second reaction comes as a challenge: “Wait – isn’t that what Iterative development is all about? The business can plan and change direction with every iteration?”

The assumption is that Iterative methodologies such as Scrum or Agile, can be an effective way to solve nonalignment situations. They break up a project into small durations (iterations) that focus on specific feature sets. An iteration may be as small as a week, but may be defined as large as four weeks. (You’d be surprised at how much energy this last point generates.)

This is often considered a safe/natural solution because at the beginning of each iteration, the business will look at the list of everything they want and define the target features they would like the team to work on for the next iteration(s). This re-planning allows the business to change its mind and adapt based on feedback and potentially changing business conditions.

An Iterative process doesn’t resolve alignment issues!

But we still have a problem here: The Business Stakeholder who kicks off each iteration is now accountable to determine what “success” is for that iteration. If they aren’t aligned with the original/other stakeholders, then they are actually steering the ship off-course. And there is NO visibility. The rest of the stakeholders may not even know what decisions and tradeoffs have been made within an iteration planning meeting.

But wait Bob! When we do an Agile project, we always have all stakeholders in the loop about which features were completed and what will be planned for the next iteration!

And to that I say: You are not the norm! So congrats!

When most organizations embrace Agile, they are focused on the core I.T. team, planning and execution. They don’t have a model for how this changes the behavior of the business stakeholders in their planning and management of initiatives.

True, we tell the business folks we want them in the room with us, giving us quick feedback, etc. But what we often don’t do is explain to them that this level of feedback requires them to constantly re-baseline what features are “in and out” based on their goals and budgets. There is no formal process for shifting this ownership over to the business.

So what’s the point?
ITERATIVE ALIGNMENT

The fact is that more often than not, a project will be started after hearing: “You Guys Start, We’ll Figure This Out Later”. It is the nature of business and politics. In fact, as I illustrated above, our iterative processes can almost “enable” a lack of alignment.

It’s important for us to set goals for the business to do regular “alignment-check-in”. We need to make sure the business owns and is accountable for understanding what they are asking for, and what changes have been made.

We should strive to eliminate the surprises at the end of a project where a business stakeholder asks:

Where did this feature come from? or
Why is this functionality missing?

Even if we followed the requirements to the letter.

So what do you think? Do you disagree? If you agree, who do you think should be accountable for managing this within your team? Within the business?

May 24, 2011 | 0 comments | View Post

What Abbott & Costello Can Teach Us About Software Requirements

Growing up, I used to love watching old black and white comedies, particularly Abbott & Costello. If you’ve never seen their classic “Who’s on First”, you can find it right here on YouTube. Feel free to watch it now (but be sure to come back)!

Briefly, this comedy skit is about Abbott explaining to Costello the names of the players on their baseball team. The names of the players include “Who” playing 1st base, “What” playing 2nd base and “I Don’t Know” playing 3rd base. Costello wants to know what the players’ names are, so he would ask “Who’s playing first base?” and Abbott would proudly respond “Exactly”. A frustrated Costello asks “What is the name of the person on first base” and now Costello would reply “No, he plays second”.

If you have never heard the routine, you must listen to it to appreciate it. The link above should help. But I digress.

“Who’s on First” can teach us a great deal about the pitfalls of collecting requirements:

We can have two business users reviewing the same requirements document, each thinking it says something very different. It gets worse. In the real world of requirements, this confusion isn’t limited to two individuals. It spans the entire team, including the business analysts, testing team and developers.

The obvious difference between the “Who’s on First” routine and real life requirements, is that Abbott & Costello know they are having a communication problem.

In the real world, the situation is actually much more challenging.

The “Spellchecker”

Let me share with you an actual “Who’s on First” example that happens almost every time we collect requirements. I call this the “Spellchecker” (and this is totally fiction, made up for illustrating my point).

Let’s pretend we need to add Spellchecker capability to our mobile application. We send out an RFP to various firms. In this example let’s say we send it out to Apple and Microsoft.

Apple responds and says they need two people working for two weeks.
Microsoft responds that they need four people working for six weeks.

We wonder: how does one company’s estimate result in four person-weeks while another is twenty-four person-weeks? Did Microsoft pad their estimate? Or did Apple simply not spend the right energy on estimating and they pulled a number out of the air?

So we ask Apple: “What are the two people going to do for two weeks”? They respond that they will build two screens and one engine. The two screens will include the screen that shows you replacement words and a confirmation screen. The engine is the actual “Spellchecker”.

Seems reasonable.

Then, we ask Microsoft: “What are four people going to do for six weeks”? They respond that they will be working on eleven screens and three engines and possibly some APIs.

Hmmm. We pause and ask: What are these eleven screens going to be used for? They explain the same two screens and engine that Apple discussed.

But they also have screens that allow you to add and maintain a list of “custom words” for your personal dictionary. Further, they have screens that allow you to plug in a proprietary dictionary such as a medical dictionary or a special language. That is how they got to eleven screens.

WOW! I never thought of that detail. Now I have to think of which version of the “Spellchecker” I really want.

If I want the two-screen version, I have to ask Microsoft to change their assumptions and re-estimate. If I want the eleven-screen version, I have to provide the clarity to Apple and ask for their re-estimate. Most likely, I may want something in between. Maybe a seven screen version. I want the “custom dictionary of personal words, but NOT the proprietary dictionaries”. So I clarify and ask them both to submit a re-estimate.

Unlike Abbott & Costello who knew they weren’t communicating, in the real world, we usually don’t catch our “Spellcheckers”. The BAs write up the requirements and the developers deliver the code. We all think: How difficult can it be to understand? After all, the business folks said they just want a Spellchecker! How much more straightforward can you get?

And later, when we deliver a solution that missed the point, the business will hold the BA and developer accountable! I mean it’s as simple as “Who’s on First”!

Taking the First Step

After sharing the “Spellchecker” story with the teams I work with, we actually use the word “Spellchecker” in our every day conversations to help uncover ambiguities and assumptions. It’s sort of a “keyword” around here.

Say we are discussing how we can’t put the next release of our software into production until we fix all of the defects that our top executive just finished screaming at us about. The developers estimate that this can take two to three months.

Our manager responds that we are estimating out of fear and these defects can be squashed in weeks. There is no way he is telling the executives that they have to wait another “three months”!

Then, someone pop-ups in the heat of this conversation and says:

Time-out. Do we have a “Spellchecker”? When you say fix “All the Defects”, we see there are over 50 defects in the system and we can’t imagine fixing all of those with four developers in a matter of two weeks.

Our manager responds:

50? No way! We only need the Severity 1 defects fixed. There are only four of those defects.

And the team responds:

That makes a big difference. Yes we should be able to get that done in a couple of weeks. But are you sure that the Executives agree to only work on the Severity 1 defects? It’s a Spellchecker to them too!

The Benefit of Acknowledging Spellcheckers

Not only do the teams I work with use the word Spellchecker to call out ambiguities, I have clients that have adopted this practice, calling out situations where they question whether “are we really talking about the same thing”. (In fact, the spellchecker concept is so useful, even my family has adopted using it).

There will always be areas that slip in between the cracks. You can’t catch every Spellchecker. However, the real benefit of acknowledging Spellcheckers is the fact that everyone acknowledges that unintentional Spellcheckers, not individuals, can be obstacles to a team’s effectiveness.

More important, Spellcheckers often point to a two-sided misunderstanding. Many times, when you uncover a spellchecker in requirements, the business person will say: I didn’t even think about that. I am not sure what I meant.

I’ll add one more example: When a business user identifies a defect in the software we delivered, we argue that this is an enhancement and not a defect. This is usually a Spellchecker in action and we are both right (or wrong)!

Now, Who Did You Say Is On First?

My suggestion is to introduce the concept of Spellcheckers to your team and ask everyone to speak up when they see Spellcheckers. Share this with your business folks, management, and everyone else involved on the project. When you identify a Spellchecker, everyone can agree that no individual is at fault. It is simply a challenge in every day communication.

I’ll leave you with a final link. I recently came across another short video that is a modern day technical version of “Who’s on First”. I hope you enjoy this as much as I did. I especially like the punch line at the end.

Please comment and let me know about how Spellcheckers create confusion in your world and any other insights on the topic.

If you think others in your network or organization would benefit from learning about Spellcheckers, feel free to share this post using the tools below.

Photo Credit: Purple Slog

April 26, 2011 | 2 comments | View Post

The Biggest Management Lie You’ll Ever Hear: “I Won’t Hold You To It”

I have to be honest on this one. Not only have I been on the receiving end of this, but I am guilty of saying these words as well:

“I need a high-level estimate. I won’t hold you to it. I know you typically need more time to create an estimate, but I am looking for an order-of-magnitude estimate. Can you get me something by tomorrow? Again, I won’t hold you to it. I know you need to do a full estimation process to give me the real number. I’m just looking for a swag.”

And then, at some point in the future, management gets the real estimate. It is almost always higher (sometimes double) and management (myself included) can’t understand how it got that way. How can you go from $100k to $125 or $150k? Or from two months to almost four months?

And, inevitably, the creator of the swag estimate is asked, “So what would it take to get down to the original estimate?”

So What is Management Really Thinking?

When you are the recipient of the line: “I won’t hold you to it”, the first question you have to ask yourself is: What was management thinking? When management asks us to provide a high-level estimate, what do they really need that number for? It seems they were saying, don’t worry about being inaccurate or way off … I won’t hold it against you! But this isn’t rational.

Management is Trying to Make a Business Decision!

They are going to use that number for decisions. Decisions at their level! Decisions that may determine:

Go/no-go on a project, or
Do I need to plan for more budget and if so, what kind of dollars are we thinking of, or
Do I need to request more staffing or can I give away resources, etc.

These are typically higher-level decisions. That means the estimates they are asking for are actually as important as any other combination of estimates we provide.

The next question: Does Management really mean it when they say “We won’t hold you to it”?

The truth is, they will hold you accountable for the number they receive. No one in leadership is going to say: Pull a number out of the air, and wink-wink, we know it’s way off. But no worries, I know you threw a dart at a board of numbers and just gave me the result squared.

What they are really saying is that they need an estimate without going through the typical rigor of process that may take days or weeks. I am not looking for a plan with milestones and staffing requirements. I am looking for an overall high-level plan without that detail information. So don’t try and cover yourself on this. I won’t create pain for you. Just give me the high-level estimate.

They may not understand, that getting them the high-level estimate requires us to build the details. Only then will the high-level numbers have enough validity so they can make business decisions based on them.

A Best Practice: Communicate Your Concerns! Call Them Out on It

The next time management says I need an estimate but I won’t hold you to it, call them out on it! Ask them what they need the estimate for and what decisions will it be used for. Are they looking to free up resources? Are they putting in a budget request? Ask how painful it will be if the estimate is off by x%? Odds are they may pad the estimate (their budgets) for planning purposes.

Start having a conversation so you can truly help management as best you can, and as a partner.

One thing is for sure, if they are asking you for an estimate, they are using it for business reasons. And, bottom line, you will be the owner of that estimate!

Estimating is a Minefield!

Estimating can be a minefield. Everyone asks for estimates. We ask a child how long a chore will take, or when they’ll be home from a party. We ask a boss when our review will be done. Marketing has been asking me when will I have this blog article complete? (By the way, they clearly tell me they will hold me to it!)

We need a consistent language around estimating and more importantly, we need consistent expectations around how we estimate and what we “can” and what we “can’t” estimate, repeatedly and predictably.

So the next few articles are going to focus on common obstacles that cause a team estimate to either be order-of-magnitudes incorrect or simply an estimate that does not command everyone’s confidence.

We’ll start next post with about padding estimates and why we should NEVER do it. I will present you a better alternative.

So, how many times has management asked you for an estimate that you won’t be held to?

Photo Credit: Denise Chan

March 2, 2011 | 1 comment | View Post

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

Last 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.

November 2, 2010 | 0 comments | View Post

Software Requirements: Are The Business People With You?

The Role of the Business in Driving Software Requirements Definition

Many of us believe that the single hardest part of building a software system is deciding precisely what the business needs. No other part of a project has as much impact on the final outcome as requirements definition. Yet, the requirements process often ends up as the area most lacking in best practices.

I recently participated in a survey of IT executives at a Chicago trade conference. Some of the results of the survey were what I expected and some were surprising. But either way, the results are very relevant for teams looking for perspective on their own development practices. This week, I’ll report some of the basic findings of the survey.

Most of the executives in the survey recognized the importance of accurate requirements and admitted to routinely struggling in two areas: Connecting with the business and managing requirements throughout the development cycle.

Key Survey Findings

94% of respondents acknowledged that the quality of requirements is a leading factor in the success of their software projects.
Over 70% acknowledged that there is room for improvement in their requirements practices.
75% agreed that better articulation of business and IT roles/responsibilities in requirements gathering would go a long way toward improving project outcomes.
While most admitted that the business has at least some input with requirements definition, requirements are often unclear.
Over 80% of respondents indicated that they do not learn about missed requirements until too late in the project development cycle.
Only about half of the respondents felt that business and IT teams have a consistent view on project status.
Over one third of respondents stated that progress is not consistently tracked in business milestones, resulting in rework and missed deadlines.

It’s Unanimous: Business Involvement Has a Big lmpact

It is not uncommon for business stakeholders to “throw their requirements over the fence” and expect to come back later to a successful working system. In practice, however, this approach leads to rework, project delays, cost overruns, and other disappointments.

Although the degree of business involvement varied within the survey, respondents overwhelming agreed that when the business is directly held accountable for clearly defining their needs, project outcomes improve. Respondents also mentioned the need for better articulation of business and IT roles and responsibilities in the requirements process.

Business Milestones: Now You See them. Now You Don’t.

Another big area of concern for survey respondents was managing requirements throughout the project. Most agreed that project metrics must define progress and value in terms the business understands and appreciates. Approximately 50% reported that business and IT teams in their organizations share a consistent view of project status.

Another important benefit of using common metrics is more awareness of when requirements are due. All too frequently, IT learns about missed requirements too late in the development cycle.

In the case of the survey, all agreed that it is critical to find out as early as possible whether key requirements are missing. However, most respondents indicated that they become aware of missed requirements during User Acceptance Testing (UAT) or after deployment.

What level of commitment do the business stakeholders have in requirements definition in your organization and how does this impact project outcomes?

Next week, I’ll write about some of the steps you can take to pinpoint the areas of your organization most likely to interfere with your ability to satisfy business expectations.

October 26, 2010 | 1 comment | View Post

How Internal Pressures Can Implode an IT Organization

When an IT Group Unravels

Many of us have gained valuable insight from articles about lack of business-IT alignment. But what about an IT organization that is misaligned with itself? How prevalent is this and what causes it to happen? There are many kinds of organizational pressures that can cause this to occur. Over the next two weeks, I will reveal how IT can implode from within.

This week, I’ll talk about what leads up to an IT organization becoming internally misaligned. But first, let’s define what “misaligned” means. It means that groups or individuals think that they are all focused on the same agendas, have the same motivations and are marching to the same objectives and goals, but in reality, they are not.

Think of a deep sea submersible designed to withstand immense pressures. During a deep dive, all it takes to implode that submersible is a single breach that isn’t discovered until it’s too late. Similarly, an IT organization may be designed to be resilient to pressures and stretching, but may have weaknesses that eventually reveal themselves and result in implosion.

So What Causes an IT Team to Become Misaligned … With Itself?

I’ve been hearing a lot lately about how IT should actually be a part of the business team and not exist as a separate entity. In reality this is not actually practiced in many organizations. For the most part, IT exists as a separate, autonomous organization. Given that this is the norm today, this post will assume that situation.

There are cases when business provides exactly what an IT organization needs to deliver value. Yet, despite that clear direction from the business, the technology group still fails to deliver. What resides at the core of this issue? Why do we still see technology groups with silo mindsets, separate agendas, different motivations, and little, if any, insight into what makes the other groups tick? I believe it all starts with a lack of understanding of how to unite these technology groups and individuals into a single, cohesive and effective functioning organization.

Separate, non-transparent, or seemingly conflicting agendas and motivations can kill any alignment within a team. Like functional groups looking to gain a competitive advantage or reduce operational costs, the technology groups are trying to manage technology costs in real-time, reduce risks, deliver value and leverage centralized technologies to support and keep pace with functional changes. Notice any real similarities in what drives groups described here? Neither do I.

I’ve never met a technology group that didn’t have the desire or best intentions of providing superior value to the business and the company. Unfortunately, passion alone will not cut it in today’s market. In fact, this passion can actually be the catalyst that exposes the IT team’s potential to implode. And that’s a good thing. It allows us to see the signs before the damage actually happens.

Is This IT Team Ready to Implode?

Have you ever been in a situation where the business summoned IT to deliver some seemingly ambiguous value on some seemingly arbitrary date? Or perhaps the business drivers weren’t communicated to everyone. You might have even wondered why an initiative was chosen and given to IT in the first place.

An IT organization may hear something like this: “The business has a strategic initiative to enable our partners to integrate into certain aspects of our operations. This will allow us to reduce costs by 3%. We need to provide them with access and limited control over certain portions of our systems and we need it no later than March 15^th. IT, please deliver this objective and start development next week.”

In this scenario, commitments were made without the technology buy-in. Technology teams often ultimately say, “We will start next week and figure it out as we go. It sounds aggressive but it should be ‘do-able’”. The functional group interprets this as a commitment from the technology group. However, without more clarity around a vision of success for this project, the business will probably not get the value they need to satisfy their agenda. And, IT will most likely be held accountable when they don’t deliver. Everyone loses.

Although the IT team had a desire and passion to help, they also set themselves up for implosion on the project. They accepted the cards they were dealt without saying “In addition to what you have provided, we need X to be successful”. In other words, they set themselves up for failure rather than move forward informed and empowered to deliver on expectations.

Next week, I will dig deeper into some of the specific pressures that can cause a team to implode and how to meet the challenges.

Has your team ever come close to implosion? What cause did you identify?

September 21, 2010 | 0 comments | View Post

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

Business/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

August 10, 2010 | 0 comments | View Post