Question

NETWORK SYSTEM MANAGEMENT.

Given the following attributes in a project management:

 Project scope & feasibility

 Documentation

 Project planning

 Testing and piloting

 Risk minimisation

Discuss briefly each of them and on how would you use them as the IT manager for the company. Provide a details information support your discussion.

Remarks:

Total 50 Marks for this questions.

Answer 1

Project Planning :-

   Project planning is at the heart of the project life cycle, and tells everyone involved where you’re going and how you’re going to get there. The planning phase is when the project plans are documented, the project deliverables and requirements are defined, and the project schedule is created. It involves creating a set of plans to help guide your team through the implementation and closure phases of the project. The plans created during this phase will help you manage time, cost, quality, changes, risk, and related issues. They will also help you control staff and external suppliers to ensure that you deliver the project on time, within budget, and within schedule.

The project planning phase is often the most challenging phase for a project manager, as you need to make an educated guess about the staff, resources, and equipment needed to complete your project. You may also need to plan your communications and procurement activities, as well as contract any third-party suppliers.

The purpose of the project planning phase is to:

• Establish business requirements
• Establish cost, schedule, list of deliverables, and delivery dates
• Establish resources plans
• Obtain management approval and proceed to the next phase

The basic processes of project planning are:

• Scope planning – specifying the in-scope requirements for the project to facilitate creating the work breakdown structure
• Preparation of the work breakdown structure – spelling out the breakdown of the project into tasks and sub-tasks
• Project schedule development – listing the entire schedule of the activities and detailing their sequence of implementation
• Resource planning – indicating who will do what work, at which time, and if any special skills are needed to accomplish the project tasks
• Budget planning – specifying the budgeted cost to be incurred at the completion of the project
• Procurement planning – focusing on vendors outside your company and subcontracting
• Risk management – planning for possible risks and considering optional contingency plans and mitigation strategies
• Quality planning – assessing quality criteria to be used for the project
• Communication planning – designing the communication strategy with all project stakeholders

The planning phase refines the project’s objectives, which were gathered during the initiation phase. It includes planning the steps necessary to meet those objectives by further identifying the specific activities and resources required to com­plete the project. Now that these objectives have been recognized, they must be clearly articulated, detailing an in-depth scrutiny of each recognized objective. With such scrutiny, our understanding of the objective may change. Often the very act of trying to describe something precisely gives us a better understanding of what we are looking at. This articulation serves as the basis for the development of requirements. What this means is that after an objective has been clearly articulated, we can describe it in concrete (measurable) terms and identify what we have to do to achieve it. Obviously, if we do a poor job of articulating the objective, our requirements will be misdirected and the resulting project will not represent the true need.

Users will often begin describing their objectives in qualitative language. The project manager must work with the user to provide quantifiable definitions to those qualitative terms. These quantifiable criteria include schedule, cost, and quality measures. In the case of project objectives, these elements are used as measurements to determine project satisfaction and successful completion. Subjective evaluations are replaced by actual numeric attributes.

Risk Minimization:-

Project risks can be very detrimental to your company, irrespective of the size of the risk. Even a simple risk can put your company out of business if not handled well. On the other hand, when you minimize risks in your projects, everyone in your company wins and the rewards can significantly propel your company forward, especially if large or important projects are successful. It is therefore imperative to analyze your projects on time in order to come up with ways to deal with the risks – or at least to minimize them – before it is too late. The core question that is often raised by many project managers is how to achieve this. Here are a few tips:

1. Identify the Risk

Basically, every project risk is a choice between many options or several paths. There may be issues at the executive level which appear to require more strategic choices; issues at the departmental levels which require resources to be sorted out; or issues at the project development stage which require material, design, and technology to solve. These might be very challenging, especially if they are minor issues which may be assumed.

However, to effectively minimize the risks associated with such issues, it is important to identify the risks so that you are aware of every choice that you need to sort every issue. This will also give you an opportunity to understand the decision that you want to make for each choice, as well as its intent and purpose.

2. Have an “Insurance Plan”

One of the vital yet often ignored ways to minimize project risks is to have a plan of the actions to take if risks occur in the course of a project. This should not be confused with any discussion on plans that nobody remembers after a meeting – it should be a solid fleshing out of some of the most probable outcomes and forethoughts on the actions to take in case of project risks.

3. Prioritize Implementation

Many project managers fear going down alternative paths, especially after investing a tremendous amount of resources into a project. When it comes to hitting an alternative implementation button, the decision feels very raw, personal, and may look like a failure. However, to minimize risks that can result from such situations, it is important to prioritize your implementation strategy to regain the momentum in your project development team. Sometimes, it even calls for abandoning a new vendor or promising technology in favor of a stable, simpler, proven, and less risky path that would enable the project to move forward.

4. Quantify the Impact of Probable Risks

Another vital way to minimize project risks is to quantify the impact of every issue. Impact can be quantified by determining the time, expense, and opportunity that is associated with every issue that arises in the course of project development. Quantifying the impact of every issue may in turn require a fresh “insurance plan” or alternative implementation details. This will significantly help in maintaining evolving strategies and will go a long way in helping minimize project risks.

Generally, project risks can be minimized with some simple strategies. Therefore, choosing the right strategies removes the fear of failure and fosters the confidence that your project will be successful in the face of any setback.

Documentation:-

Project documentation covers documents created during and for the project itself. Examples include the overall project vision, the project plans, the schedule, and the risk analysis. The documentation process has a deeper purpose than merely creating piles of paper.

• Documentation stimulates and structures critical thinking in planning the project's goals, risks, and constraints. The document is the evidence and chronicle of this critical thinking.
• It provides memory containers for managing a level of detail that cannot be kept in people's heads. This includes the small details easily overlooked during day-to-day project work, as well as the larger things easily remembered today, but potentially lost or forgotten due to the passage of time or critical personnel changes.
• It keeps the team and other stakeholders synced up and informed about project changes, issues, and progress.

In many projects, the documentation is often done late, done poorly, or not done at all—usually because the documentation is perceived as having little or no value. And, in fact, this is true if the documents are created as an afterthought or a necessary evil. Even documents with adequate content will lose value if they are created at the wrong time during the project, or aren't used in the project management process. Here are some examples:

• Timing: If the project documentation is created at the wrong project stage, it may have little or no value, even if its content is quite good. Examples: a vision document created late in the project; a detailed schedule created before the stakeholders have agreed on an overall project vision.
• Use: If the plan, vision, or risk analysis documents are created and then rarely or never referenced, they will likely have little or no value except for generating some initial critical thinking during their creation. Examples: a risk analysis that isn't referenced to measure progress on mitigations, or updated with newly discovered risks as they occur; a requirements document that isn't referenced later as a design completeness checklist.
• Content: Inadequate or incomplete content decreases a document's value, even if it is created on time and used correctly. Examples: a status report for product development that doesn't track the product costs; a risk analysis that doesn't include risk mitigations.

A key reason for documenting is to reduce the risks in the project. The level of detail in even the simplest project is simply too great for the human brain to capture, remember, and manage. Properly done, project documentation is a dynamic, animated extension of the brains of the stakeholders. It allows us to focus our limited mental processing and decision making on different areas of the project at different times, without having to keep the entire detailed state of the project in our heads.

Project Scope and Feasibility:-

Scope:-

Project scope is the part of project planning that involves determining and documenting a list of specific project goals, deliverables, tasks, costs and deadlines. The documentation of a project's scope, which is called a scope statement, terms of reference or statement of work, explains the boundaries of the project, establishes responsibilities for each team member and sets up procedures for how completed work will be verified and approved. During the project, this documentation helps the project team remain focused and on task. The scope statement also provides the project team with guidelines for making decisions about change requests during the project. Please note, a project's scope statement should not be confused with its charter; a project's charter simply documents that the project exists.

It is natural for parts of a large project to change along the way, so the better the project has been "scoped" at the beginning, the better the project team will be able to manage change. When documenting a project's scope, stakeholders should be as specific as possible in order to avoid scope creep, a situation in which one or more parts of a project ends up requiring more work, time or effort because of poor planning or miscommunication. Effective scope management requires good communication to ensure that everyone on the team understands the scope of the project and agrees upon exactly how the project's goals will be met. As part of project scope management, the team leader should solicit approvals and sign-offs from the various stakeholders as the project proceeds, ensuring that the finished project, as proposed, meets everyone's needs.

The importance of defining a project's scope

Here are the benefits a project scope statement provides to any organization undertaking a new initiative. It:

• articulates what the project entails so that all stakeholders can understand what's involved;
• provides a roadmap that managers can use to assign tasks, schedule work and budget appropriately;
• helps focus team members on common objectives; and
• prevents projects, particularly complex ones, from expanding beyond the established vision.

Project managers generally find that establishing project scope ensures projects are focused and executed to expectations. The scope provides a strong foundation for managing a project as it moves forward and helps ensure that resources aren't diverted or wasted on out-of-scope elements.

How to define the scope of a project

Defining project scope requires input from the project stakeholders, who together with project managers establish the key elements of budget, objectives, quality and timeline. To determine a project scope, project managers must collect requirements for what the stakeholders need from the project -- this includes the project's objective or the project's deliverables, when the project needs to be completed, and how much they can pay for it. The goal is to gather and record precise and accurate information during this process, so that the project scope effectively reflects all requirements and thus improves the chances for project leaders to deliver products that meet stakeholder expectations on time and on budget.

Feasibility:-

As the name implies, a feasibility analysis is used to determine the viability of an idea, such as ensuring a project is legally and technically feasible as well as economically justifiable. It tells us whether a project is worth the investment—in some cases, a project may not be doable. There can be many reasons for this, including requiring too many resources, which not only prevents those resources from performing other tasks but also may cost more than an organization would earn back by taking on a project that isn’t profitable.

A well-designed study should offer a historical background of the business or project, such as a description of the product or service, accounting statements, details of operations and management, marketing research and policies, financial data, legal requirements, and tax obligations. Generally, such studies precede technical development and project implementation.

Five Areas of Project Feasibility

A feasibility analysis evaluates the project’s potential for success; therefore, perceived objectivity is an essential factor in the credibility of the study for potential investors and lending institutions. There are five types of feasibility study—separate areas that a feasibility study examines, described below.

1. Technical Feasibility

   This assessment focuses on the technical resources available to the organization. It helps organizations determine whether the technical resources meet capacity and whether the technical team is capable of converting the ideas into working systems. Technical feasibility also involves evaluation of the hardware, software, and other technical requirements of the proposed system. As an exaggerated example, an organization wouldn’t want to try to put Star Trek’s transporters in their building—currently, this project is not technically feasible.

2. Economic Feasibility

   This assessment typically involves a cost/ benefits analysis of the project, helping organizations determine the viability, cost, and benefits associated with a project before financial resources are allocated. It also serves as an independent project assessment and enhances project credibility—helping decision-makers determine the positive economic benefits to the organization that the proposed project will provide.

3. Legal Feasibility

   This assessment investigates whether any aspect of the proposed project conflicts with legal requirements like zoning laws, data protection acts or social media laws. Let’s say an organization wants to construct a new office building in a specific location. A feasibility study might reveal the organization’s ideal location isn’t zoned for that type of business. That organization has just saved considerable time and effort by learning that their project was not feasible right from the beginning.

4. Operational Feasibility

   This assessment involves undertaking a study to analyze and determine whether—and how well—the organization’s needs can be met by completing the project. Operational feasibility studies also examine how a project plan satisfies the requirements identified in the requirements analysis phase of system development.

5. Scheduling Feasibility

   This assessment is the most important for project success; after all, a project will fail if not completed on time. In scheduling feasibility, an organization estimates how much time the project will take to complete.

Testing and piloting :-

Pilot Testing is defined as a type of Software Testing that verifies a component of the system or the entire system under a real-time operating condition. It verifies the major functionality of the system before going into production.

This testing is done exactly between the UAT and Production.

In Pilot testing, a selected group of end users try the system under test and provide the feedback before the full deployment of the system.

In other words, it means to conduct a dress rehearsal for the usability test that follows.

Pilot Testing helps in early detection of bugs in the System.

Pilot testing is concerned with installing a system on a customer site (or a user simulated environment) for testing against continuous and regular use.

The most common method of testing is to continuously test the system to find out its weak areas. These weaknesses are then sent back to the development team as bug reports, and these bugs are fixed in the next build of the system.

During this process sometimes acceptance testing is also included as part of Compatibility Testing. This occurs when a system is being developed to replace an old one.

In Software Engineering, Pilot Testing will answer the question like, whether the product or service has a potential market.

Why do Pilot Testing

The most important objective of Pilot Testing is to debug the software and procedure you will use for the test.

• It will help to check if your product is ready for full-scale implementation
• It will help to make a better decision on allotment of time and resources
• It will give an opportunity to gauge your target population's reaction to the program
• It will help to measure the success of your program
• It will give the team a chance to uncover and practice the activities they will be using during the usability test.

How to do Pilot Testing

The level of Pilot testing depends on the size and scope of your migration project. The actual Pilot testing is done in a dedicated area or lab where users run numerous procedures, transactions, and reports as they simulate the software's functionality.

Pilot testing can be conducted depending on the context of the project,

• For a general business enterprise, a pilot test can be conducted with a group of users on a set of servers in a datacenter
• For a web development enterprise, a pilot test can be conducted by hosting site files on staging servers or folders live on the internet
• For commercial software vendors, a pilot test can be conducted with a special group of early adopters.

Pilot testing involves following Test Plan

Step 1: Create a Pilot Plan

Step 2: Prepare for the Pilot test

Step 3: Deploy and test the Pilot test

Step 4: Evaluate the Pilot test

Step 5: Prepare for production deployment

Before conducting a Pilot Testing following things need to be considered,

• Provide adequate training to participants
• A rollout plan for deploying the servers and preparing systems for the pilot
• Documentation of the installation process
• Testing scripts for each software application. It consists of checklists of functions to be executed
• Provide constant feedback to the design and testing teams from users by using emails or websites
• Set the evaluation criteria for the pilot, like information about the number of users who were dissatisfied, the number of support calls and requests, etc.
• Engage a working group of community partners or stakeholders who have invested in your project and will meet regularly to discuss your progress
• Developed an evaluation plan and evaluation instruments/tools to capture the necessary information about knowledge, changes in attitudes and behavior of the pilot group.

During the Pilot test, the team gathers and evaluate test data. Based on these data, the team will choose one of the strategies.

• Stagger Forward- Deploy a new release candidate to the pilot group
• Roll back- Execute the rollback plan to restore the pilot group to its previous configuration state
• Suspend- Suspend pilot testing
• Patch and Continue- Deploy patches to fix the existing solution
• Deploy- Proceed to a deployment of the solution

Good Practice for Pilot Testing

• Schedule the pilot test two days before the usability test.
• Do not initiate pilot test until all users, customers and project team agree on the criteria for a successful result
• Ask users to mark any issues on their copies of materials, describe their concerns, and offer suggestions (if they have any) for improvement.
• Inform to users the purpose, length, and progress of the pilot