Virtual Teams: Key Success Factors – Part 3

As we identified in Part 2 – seven key success factors for virtual teams are:

• Human resource policies
• Training and on-the-job education and development
• Standard organizational and team processes
• Use of electronic collaboration and communication technology
• Organizational culture
• Leadership support of virtual teams
• Team-leader and team-member competencies

In this Part 3, let’s look deeper at the final three of these: organizational culture, leadership support, and team competencies.

Organizational Culture

Organizational culture includes norms regarding the free flow of information, shared leadership, and cross-boundary collaboration. It helps to create organizational norms and values that focus on collaboration, respecting, and working with people from all cultures, keeping criticism constructive, and sharing information. The organization’s culture sets the standard for how virtual team members work together. An adaptive, technologically advanced, and nonhierarchical organization is more likely to succeed with virtual teams than is a highly structured, control-oriented organization.

Read more »

Final Thoughts on Requirement Prioritization

Your first priority in the requirement prioritization may be selling the stakeholders on the concept of prioritizing requirements before design start.  This isn’t an easy task.  As we discussed, a customer stakeholder is likely to react with the notion that you’re actually trying to eliminate requirements.  You have to convince them that this is not the case.

Once the stakeholders agree to prioritizing requirements, you will guide the stakeholders through the prioritization process.  Then, you will incorporate the results into the project or the product development schedules and budgets.  You must enforce the priorities throughout the development process.

As development progresses, you will identify situations that trigger use of the priorities.  These situations may include: impending resource shortages, changes in external constraints or expectations, and conflicts.  You must ensure that the priorities rule the outcome.

Requirement prioritization early in development helps a manager control project risk and change.  Knowing requirement priorities focuses a product or project development team and guides intelligent choices for phasing in product features over time.  It prevents the “bailing” that so often occurs just before delivery, in which partially implemented requirements are thrown overboard in a frantic effort to save dwindling resources for finishing the critical components.  Above all, it’s one more communication channel between customers and developers.

Read more »

Getting Stakeholders Onboard with Requirements Prioritization

Defining requirements is all about communication between customers, project managers, and developers.  Requirement priorities improve communications between these main parties.  The payoff is not obvious to everyone, however, and you will probably have to sell the concept of prioritization to your stakeholders.

Customer resistance

An external customer is probably the hardest stakeholder of all to sell on the concept of prioritization.  Customers have difficulty with the concept.  Requirement prioritization on the surface may appear to the customer to be of primary benefit to the developer, thus leaving you with a tough selling job on prioritization to the customer.  Many customers initially view a request to prioritize requirements as a backdoor way to reduce the number of requirements and they are very reluctant to do that.  A prioritization effort involving both the customer and the developer perspectives will separate essential from desirable, needs from wants, in a way not possible from only one side’s perspective.  The customer may decide to drop the low-priority “desirables” after such a review.  The customer may actually reach this conclusion on their own and that’s a good thing, though the overall project budget and timeline may need to be changed – elimination of requirements would require a change order or series of change orders.

Read more »

Should Requirements be Prioritized?

Before starting design on a project, it may be a good idea to prioritize your requirements.  Why?  Because grouping requirements together by relative importance can help you down the road with the customer in terms of flexibility in tradeoffs, design, and implementation should scope start to creep … as it usually does.

You’ll need the customer onboard to perform any requirements prioritization and that’s not an easy thing to do, but enlisting the customer in this effort and doing it at the beginning of the project before you actually spend resources on project requirements can give you the best flexibility.

Making a case for prioritization

If you postpone requirement prioritization and you end up facing a resource shortage, you may find yourself throwing away work already performed on lower priority requirements in a panic effort to focus on and finish the truly important ones.  By the time a crisis like that comes in to play, it may be too late to fix it with prioritization.  The portion of the project or product developed with the lower priority requirements may be too tightly intertwined with the portion implementing higher priority requirements to do anything about it.  Dropping some requirements late in the development process may require major and expensive rework on the project and end solution.

Knowing requirement priorities early can help avoid the late-stage implementation train wreck.  Prioritizing your requirements before design starts provides options to manage requirement additions and risk, enables delivery of a useful product in spite of changes in schedule and resource allocations, and guides architecting and design tradeoffs.

Read more »

Scoping the Project for Better Requirements

Good scope before requirements

The earlier you define scope, the more efficient your requirement definition process will be. Work done before scope definition is usually wasted effort. An early scope definition keeps requirements writers from diverging, reduces requirement inconsistencies, and keeps the big picture in view. It also shortens the time required for requirement writing and rewriting and reduces debates.

If you do not give everyone writing or reviewing requirements your scope definition, they are likely to create their own. Imagine listening to a movie without watching it – as I have done many times on trips in the SUV listening to a movie several times but never seeing it as it’s playing in the DVD player behind my head. I have a vision – my own vision – of what’s going on and what the characters look like and what the set looks like, but if no one describes it to me in detail or I don’t see it for myself then that’s all it is … my own vision. And it likely differs greatly from the actual film itself. Read more »