Archive for the ‘Project Management’ Category

Solutions for the Requirement Gathering Process

Friday, October 26th, 2007

Gathering the requirements for a new system takes time. Imagine what it is like to record the opinions and demands of dozens of employees, sort the priorities and then make them work side by side while implementing the software rollout. The requirement gathering process (RGP) is often the cause of project failure because it drains an organization’s resources before a new system is even implemented and tested. Over the past three decades, organizations have slowly improved upon the RGP and have discovered and actualized various methods of success. There have been three notable attempts at rapid application development (RAD). Two proved unsuccessful, though factors from each are still being used in the third and seemingly successful attempt at RAD.

The first attempt at RAD was the introduction of the business analysts (BA) position, who was business minded but also trained in IT. By creating a ‘bridge’ between business users and IT, information that was often lost in the jargon between business users and IT was reclaimed. Although a blessing at first, BAs soon became technicians in their own right and began to guide and provide information rather than translate it, further distorting the messages between business users and IT. In this three part series I will continue to illustrate progress in RAD.

Why Requirement Gathering Can Kill Your Project, III

Wednesday, October 24th, 2007

Difficulties in Compromise
Because it is difficult to gain access to business users, IT makes many of the systems compromises alone. Thus business users are delivered a system which they say is not what they wanted.

Difficulties in Reaching Decisions
We are minimally trained in the art translating information from one source to another. As a result meeting discussions tend to move around in circles, move off on tangents, or worse lack a clear purpose of discussion. Add the complication of system development to the mix and you can find yourself going nowhere

These factors can certainly be changed. With experiments and varying tactics being used in the requirement gathering process, some companies have been more successful in completing projects under time and under budget. These changes and advancements are discussed will be discusses in my next blog series.

BigWave can help you manage multi-site IT projects more efficiently so you can collaborate and communicate quickly and effectively both on and off site. With BigWave, project managers can focus on what they do best—managing projects. Contact BigWave today to eliminate the chaos and streamline your multi-site project management.

Why Requirement Gathering Can Kill Your Project, II

Thursday, October 18th, 2007

Difficulties in Visualization
Rather than formulating overall requirements, business users are often asked to visualize all of the details they believe the system should have, and to then imagine how those requirements might coexist while also working with or replacing the current system. It is nearly impossible to organize and visualize such details, not to mention quite intimidating to the employees whose opinion is being sought and who might not be comfortable with complicated projects like multi-site project management.

Difficulties in Gaining Access to People
IT projects are frequently treated as a second priority to all other duties that a business user might have. It is not uncommon that on top of a 10 hour work day, a business user must then go and contribute to the requirement gathering process. Business users become exhausted and frustrated by an additional commitment, often making themselves inaccessible. Thus it becomes difficult for IT to gather all of the information it needs to continue forward with a project. In such instances IT finds itself making decisions without the participation of the user.

BigWave can help you manage multi-site IT projects more efficiently so you can collaborate and communicate quickly and effectively both on and off site. Contact BigWave today to eliminate the chaos and streamline your multi-site project management.

Why Requirement Gathering Can Kill Your Project

Tuesday, October 16th, 2007

Developing and implementing a new software application is a long and arduous process. Despite the belief that it is the building, implementation and testing period that consumes most of the time, the gathering of system requirements actually swallows up most of the time and budget allotted for the project. Recent research suggests that up to 80% of a project’s allotted time is spent gathering the requirements of a new system. Developers have done their part in reducing the time spent by implementing tools such as Rapid Application Development and automated testing tools and have become well acquainted with such processes as multi-site rollouts, software rollouts and POS rollouts. But it is to no avail, as companies continuously face the challenge reducing their requirement gathering time.

Spending too much time on gathering requirements could ultimately kill your project. Recent research shows that of 8,500 projects conducted in the US, 31% were never completed. The factors contributing to these failures include lack of user input, incomplete and changing requirements and specs, and lack of executive support — all of which occur in the requirement gathering phase. This three part series I will discuss five major causes for the difficulties in gathering system requirements.

The Software Purchasing Process, III

Friday, October 12th, 2007

Part 3 of a 3-part series

Further Define Your Needs
After the demonstrations, you and your selection committee should narrow your choices down to 2 to 4 packages. At this time it is necessary to further define your needs based on the demonstrations. Each need should be rated as follows:

  • Exceeds requirements
  • Good fit with requirement
  • Fits with a workaround
  • Can be modified to fit
  • Will not fit requirements


Technical Review

After evaluating your detailed requirement, you should find yourself down to one package. Conduct a technical review with your chosen package. A technical review should cover the following:

  • Does it play comfortably with other software?
  • How easy is it to build and interface?
  • How customizable are screens and reports?
  • What are bandwidth requirements?
  • How much effort is required for the software rollout?
  • What happens under load?
  • How easy is backup and restore?

Final Steps
You are almost there. Before you sign the deal, it is best to do the following:

  • Check Reference Sites
  • Negotiate the Price
  • Iron out any contractual issues
  • Review implementation effort and cost

BigWave can help streamline your software rollouts. Contact us today for more information!

The Software Purchasing Process, II

Wednesday, October 10th, 2007

Part 2 in a 3-part series

Educate Yourself and Define Your Goals
Once your organization has committed to purchasing software, bring in an independent expert to teach you, and your selection team about the software you are looking for. Scan the market and identify all potential packages. Make a list of approximately 20 “must haves”. These requirements might relate to:

  • Operating systems
  • Cost
  • Time to implement
  • POS Rollouts
  • Compatibility with other software
  • Local support
  • Access to source code
  • Vendor size
  • Functionality
  • Multi-Site Rollouts

Scan the market and identify all potential packages that match your listed criteria.

Arrange a Software Demonstration
Have vendors demonstrate their software to you and your selection team. Prior to the demonstration it is imperative that you create an agenda that covers everything you want to see. At the time of demonstration be sure to do the following:

  • Give a copy of the agenda to each member of the selection team.
  • Let the rep know that you have an agenda, and be sure that he agrees to follow it.
  • Tell that rep that all future contact is to be through you

The Software Purchasing Process

Thursday, October 4th, 2007

Your organization is in need of new software, and although many people believe that the purchasing process is simple, you know better. A software purchase requires careful thought as a poor purchase can lead to such atrocities as mismanaged stocks, invoices or financials, and ultimately to an organization’s collapse. In this three part series, I will outline the necessary steps one should follow in an effort to avoid such a mishap.

Before You Even Begin Look at Software
It is imperative to check that the executives understand the complexity involved with implementing company wide software. Some concerns that should be addressed include:

  • Software selection is a rigorous process and will involve a number of people.
  • Implementation will probably cost more than the purchase.
  • The current business process will need to change.
  • Customization may turn out to be extremely expensive, and may still not deliver the desired results.
  • Skilled personnel will likely be pulled away from multi-site project management during selection and implementation.

Once you convince your organization to commit to the software purchase, you can choose a selection team and begin to look at the needs required of the new software.

Causes for IT Project Failure, III

Tuesday, October 2nd, 2007

Part 3 of 3

Communication:
We all know the importance of communication. But it is often ignored in a large scale project such as a POS rollout. Project teams can be very busy, yet the executive management sees no progress. It is the Project manager’s job to communicate any progress, if only a little, to his or her executives. By doing so, a project manager will gain much needed support. Nothing good comes from keeping your employer in the dark, even if there is very little to share.

Skills:
Lastly, if you aim to be an IT Project Manager, make sure you are prepared to take on the responsibility. You may be an IT wiz, but remember that project management also requires excellent oversight, organization and communication skills. Finding a qualified IT manager is can be tough, but if a company finds someone with the winning combination who can avoid the problems listed above, there is no reason why a company’s growth should not continue.

BigWave can help you manage multi-site IT projects more efficiently so you can collaborate and communicate quickly and effectively both on and off site. With BigWave, project managers can focus on what they do best—managing projects.

Contact BigWave today to eliminate the chaos and streamline your multi-site project management.

Causes for IT Project Failure, II

Thursday, September 27th, 2007

Part 2 in a 3-part series

Goals and Objectives:
Staff members involved in IT projects often complain about unclear goals and objectives. In projects like software rollouts, project managers must develop and communicate clear objectives, while also minding the number of goals the projects might have. Although goals are a good thing, too many may ultimately confuse and distract a staff from the project at hand. It is also important to limit unexpected changes in user expectations and requirements as a project progresses. Changing expectations without clear communication will no doubt dissatisfy your customer, frustrate your employees, and add unnecessary costs.

Time estimates:
Time is of the essence – especially for project managers. When planning a project, a well calculated time frame is imperative to an accurate budget. Project managers make the common mistake of assuming the total time needed for a project’s completion is equal to the time on task. However, this does not account for interruptions. Project managers need to focus on the total duration of time needed (which includes interruptions), rather than the time on task.

More to come in the next and final post on this topic… in the meantime, BigWave can help eliminate many of the causes of IT project failure. Contact BigWave today for more information.

Causes for IT Project Failure, I

Monday, September 24th, 2007

Part 1 in a 3 part series

As the demand and size of a company grows, the role of the project manager becomes increasingly important. In an ever increasing technology-based world, multi-site project management is becoming the norm, and thus our project managers find themselves carrying much of the weight of a company’s success on their backs. Despite the fact that technology clearly improves productivity by streamlining processes and enhancing efficiency and effectiveness, many IT projects are failing. Why? There are several causes for failure. In this three-part series I will provide advice on how you might avoid them. They include:
• Poor planning
• Unclear goals and objectives
• Changing objectives during the project
• Unrealistic time estimates
• Lack of executive support and user involvement
• Failure to communicate and act as a team
• Inappropriate skills

Planning:
Project managers often plan poorly for IT projects, especially in multi-site rollouts. Unfortunately for them, they are not often given enough time to plan, or worse, the project is already on its way before it is defined. Taking a step back and planning multi-site rollouts, even if it has already started will save time and money in the long run. It is important to define a critical path, as many activities can only start once another activity is complete. Risk calculations must also be completed and taken into account.

More to come in the next post… in the meantime, BigWave can help eliminate many of the causes of IT project failure. Contact BigWave today for more information.