Subscribe via RSS Feed

Tag: "IT"

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

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

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

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

 

About to Start Requirements? Read this First.

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

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

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

How do you work with the business?

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

How do you track projects?

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

Are project roles and responsibilities clearly defined?

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

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

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

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

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.

Respondent-Roles-1

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.

ssp_temp_capture

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.

ssp_temp_capture2

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

Roadmap with cities and distances

Know where you are today. Be clear on where you’re going.

Last week, I talked about some of the many organizational pressures that can implode an IT team.  In fact, some of these may apply to other parts of the organization as well.  This week, I’ll take a look at an approach that can shed light onto solving these issues.

It’s All About Perspective

The ability to look inward in a truthful, non-self-serving manner is a phenomenal attribute to possess.  The same holds true when looking at an organization that you’ve helped create.  Allowing myself to pull out from working within the team to working on the team has afforded me valuable insights.  This ability to change perspectives is the best way to look around and objectively survey the landscape.

Once I change my perspective, the focus becomes applying a very simple approach that has been invaluable to me over the years.  Three steps: Where do we want to be, where are we now, and how do we get there?  In that order.

Where Do We Want To Be?

What may have worked well a few years ago may not be the optimal solution for today.  This is simply because our surroundings continually change.  So, resetting the baseline and re-establishing alignment can be a continual process.  Understanding how the organization will be measured and knowing what problems you’re trying to solve today will be the starting point to crafting your solution.  Not knowing where you want to be is like driving a car with a blindfold.  You’re bound to hit something and you won’t get anywhere.

Getting the right group involved is a great way to start the alignment process.  During that process, it may become clear that others have different agendas, goals and ideas on how something should be implemented.  Facilitating this group alignment on where the organization needs to be and establishing a common vision will allow everyone to head in the same direction.

This is also the time to make sure your goals will solve the problems as they are perceived today.  If silos exist or technology is scattered as I described last week, then perhaps one of the goals is to look at how to create horizontal technologies that can be shared amongst the silos.  The goal could be as simple as creating a shared platform which has an added benefit of getting the teams communicating more.

Where Are We Now?

This is where taking a step back is the most helpful.  Being immersed in something for an extended period of time gives us a single perspective of what we know to be true.  Because many teams have a lot of knowledge about what already exists (after all, they live it every day) it can be tempting to breeze through this phase.  Do not breeze.  Do.  Optimally, document the enterprise architecture of the technologies, processes and roles that exist.  You will most certainly uncover some interesting aspects of your surroundings that were previously based on assumptions.  If you have found this to be true in your experiences, please share in this blog discussion!

How Do We Get There?

This is the part where a roadmap is created.  This is typically the most difficult phase.  It has been equated to creating a solution to changing the tires on a moving race car.  It can be difficult, but do-able.

Not only is this the most challenging phase, but it’s also my favorite.  This is also the same phase where you should consider inviting the solutioning team from the first phase. They are invested in the destination, so it only makes sense that they should have some passion and energy around getting everyone else there.  Don’t go it alone.  Following this approach, you will begin seeing a team start to craft a common vision and a plan that is designed to accomplish what may have previously been thought as impossible.

The Bottom Line

Continually measuring and re-aligning has helped me immensely in preventing my teams from imploding.  This is not a tool that gets used once and discarded.  It’s designed to be used continually.  The frequency will be determined by the velocity of change in your organization.

Discussion

  • How have you had to cope with organizational pressures and how did you get started toward resolution?
  • How did you engage the right people for the solutioning phases?
  • What obstacles did you overcome?
  • What other pressures have you seen implode or hurt an organization?

Photo Credit: Goldemberg Fonseca

October 5, 2010 | 0 comments | View Post

How Internal Pressures Can Implode an IT Organization

Implosion1Last week, I talked about some of the organizational mindsets that lead to misalignment within an IT team. This week, I’ll look more closely at some of the specific pressures that can cause problems for the team and impact IT team performance. These are based on some of my own experiences in my role as an Architect.

Team Silos and Lack of Communication

Larger IT organizations often contain splintered groups that focus on either specific functional or technological areas. These groups can easily become silos. This can result in redundant efforts and solutions, dissimilar technologies, or disjointed entry points for business requests. More importantly, these silos may not easily communicate, inhibiting collaboration. Probable result: If a technology group makes changes and deploys, they run the risk of clobbering another team’s systems. Usually, they won’t know about it until production issues arise. The teams are neither in alignment on technology, people or process. This has the potential to bring progress within the IT organization to a standstill.

Pressure to be Bleeding Edge

Have you ever witnessed a technology team adopting new technologies for the sake of being bleeding edge? This desire to be bleeding edge is another factor that can cause pressure on the IT team. There are certainly many cases where new technology solves problems and creates additional efficiency. But what about the team that wants to utilize a new technology only for the sake of playing with new technology? It may perform the same function as the current technology, but just does it in a different way. Is there any value in that?  Does it help attract talent? Can it be adopted and integrated without any additional effort? Does it position the team to becoming more nimble? Does it align with long-term objectives of not only IT but the organization as a whole?

If some members of the team answer “yes” to these questions and some answer “no”, then the use of some new technologies can cause misalignment on the IT Team.  They may either have conflicting agendas or may just be out of alignment with how they need to accomplish the task-at-hand.

Teams That are Always Stretched

Stretching from time-to-time can be very healthy. It keeps a team aware of their limits and capabilities. It also helps a team to gel and rally around an effort that has a sense of urgency. Then, during the non-stretch times, it allows the team to think strategically, place more focus on refactoring which will allow it to scale for the next stretch. On the flip side of that, a team that is never stretched can have morale issues and may not deliver value at the velocity that is expected. But while the resulting atrophy isn’t healthy, teams that are always stretched are in worse condition. Stretching can result from task overload, following an antiquated process, working with unfamiliar technologies and working toward an unrealistic goal.

In any of the situations above, design and development decisions are usually made with the highest priority being: “Get this pain away from me as quickly as possible”. Decisions consistently made in this mode, usually create technical debt. If an IT organization consistently resorts to short term fixes, it compromises its potential and future progress and we begin to see implosion at the organizational level — not a sustainable plan.

What are some of the pressures has your IT team faced recently?

Next…

Next week, I will delve into some of the approaches that can be used to rectify these situations or prevent them from happening in the first place.

September 28, 2010 | 0 comments | 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 15th.  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

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

Learn to speak a common language

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

Create a common view of success

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

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

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

Allow your business partner to manage change

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

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

Be open and demonstrate your integrity

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

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

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

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

feature photo credit: dotbenjamin
post photo credit: Aidan Jones

August 10, 2010 | 0 comments | View Post
« Previous Page