Develop a strategy for requirements gathering

In most mid-sized IT organizations the process of gathering requirements is a little more advanced than scribbling a few wire frame representations of what the screen for the new system should look like. (A wire frame is simply a line drawing with boxes, rectangles, and text which roughly describes what the final product may look like.) This mechanism for collecting requirements is quick. After a few minutes and a handful of sketches, enough information can be gathered to start developing a solution.

This technique does have its place. It's a necessary part of the overall process. However, there's more to requirements gathering than getting an initial framework. Understanding the differing goals of the requirements process is an important key to understanding how to get requirements done right.

Requirements for scope
The first stage of requirements gathering is designed to establish a rough scope of the project, a process often called simply scoping. The objective is to provide a general framework for how much activity will be necessary to create the solution without delving into the specific algorithms, formulas, and techniques which must be used.

The key to managing requirements for scoping is to remember that it's a continuous process where the accuracy of the estimate improves with additional information about the problem

The scoping part of the requirements process should start the requirements process and provide a foundation for the estimated costs. Periodic review of the scope and associated estimate can help you make sure that you're on track. A final estimate, which will become the basis for the project plan, should punctuate the close of the requirements phase.

Requirements for detailed understanding
The requirements phase that most people think about when talking about requirements is the phase where detailed requirements are gathered so that a detailed design specification can be created. The requirements process is often thought of as the prelude to the design phase and is a phase where detailed user requests are cataloged, prioritized, and organized.

This part of the requirements process--capturing detailed user requests and organizing them--is needed to proceed to a design step. Whether the process is a traditional waterfall process or something more radical, it's necessary to understand the problem and, in some cases the proposed solution, in order to be able to design a solution or to design how the solution will work.

This requirements process will take longer time compared to requirements scoping.

(read complete article)

Art of Delegation

This excerpt is taken from ZDNet Asia Tech Management Update

You want to empower the team to make as many decisions as possible. This helps the project team feel more professional about their jobs and the level of responsibility they have. This can also help morale, since people generally feel better about their jobs if they feel they have a level of control over the things that impact them. As a project manager, you need to encourage people to accept responsibility and make decisions when appropriate. This helps the team run more efficiently and allows individuals to grow professionally.

As a project manager, you need your team members to handle all the day-to-day problems and only bring items to you on an exception basis. At the same time, the project manager should resolve as many problems as he can, and only bring true issues to the sponsor for assistance.
If you really empower your team with decision-making authority, it might seem that they will be able to handle any and all problems without taking them to the project manager. Actually, this would be taking the empowerment process too far. There are some problems that arise that will need to be escalated to the project manager. Likewise, there are some problems that the project manager will need to escalate to the sponsor and other appropriate managers.

Some criteria to ask about the problem so that your project team knows whether the resolution is outside their control.

• Will the resolution result in an impact to duration or cost? If there is, the project manager must be involved. The project team members cannot make changes to the project cost or duration without project manager, and probably project sponsor, involvement
• Will the decision require you to go out of scope or deviate from previously agreed upon specifications? This happens all the time. In many cases, the project team members feel empowered to take on scope change requests. This is not right. Even if the scope change is made without impact to cost or schedule, the project manager must always be involved to manage changes to scope.
• Is the problem and/or potential resolution politically sensitive? If so, the project manager must be involved. These types of problems may require escalation to the sponsor and management team as well.
• Will the decision require you to miss a previously agreed upon commitment? If so, the project manager must be involved since he or she keeps the schedule and must be involved in any decisions that result in changes to an activity end date.
• Will the decision open the project to future risk? If so, the project manager must be involved, since the project manager is responsible for the risk management process.

If none of these conditions are true, then the team member can make the decision. Most of the decisions that are required on a day-to-day basis do not meet these criteria and can be made by the team or individual team members.

IBM WebSphere Status Check

Find out how IBM WebSphere stacks up in the application integration and middleware markets.

"IBM WebSphere is one of the fastest growing areas in Big Blue's US$15 billion, 85-percent-margin software business. WebSphere revenue has grown in each of the last 28 quarters, with 18 percent growth in the second quarter of 2005. WebSphere Application Server grew 24 percent in that quarter as well. IBM software is responsible for one-third of IBM's profit annually.

IBM's ability to offer customers business flexibility in this growing market continues to beat the competition. IBM holds 37.2 percent of the global market in overall application integration and middleware, according to Gartner. Its competitors were well behind, with BEA losing market share in 2004 to 7.2 percent, Oracle at 4.4 percent and Microsoft with 4.3 percent. According to Gartner, the market should grow to US$7 billion in 2005 as companies expand existing systems, especially when considering implementing Web services and service-oriented architectures (SOAs)...."

more...