You are here: UK Essays » Essays » Project Management » Stakeholder Processes Project

Cookie Information

Privacy Information

Stakeholder Processes Project

Primary, Secondary and Tertiary Stack Holders:

A stakeholder is any person, group or institution that has an interest in a development activity, project or programmed. This definition includes intended beneficiaries and intermediaries, winners and losers, and those involved or excluded from decision-making processes.

Stakeholders can be divided into two very broad groups:

• Primary stakeholders: those who are ultimately affected, ie who expect to benefit from or be adversely affected by the intervention;

• Secondary stakeholders: those with some intermediary role. In an enterprise project these might include some of: DFID, trades unions, banks, Ministry of Finance, local government, export promotion agencies, business service providers

• Tertiary Stakeholders: Local opinion leaders (church, business or trade union leaders, teachers, local celebrities), Local media,Ecology departments of universities, research institutes

Key stakeholders are those who can significantly influence the project, or are most important if DFID's objectives are to be met. Both primary and secondary stakeholders may be key stakeholders.

The Purpose of a scope document and what Sections it should contain:

The Plan will be developed in consultation with stakeholders through a series of workshops and will identify key priority areas for development and funding. It will establish a process that will facilitate a regular review of strategies and priorities to ensure the Plan remains relevant.

Background & Business Objectives

An IT Enabling Plan approved in 2001 has primarily driven IT strategies at UWS. The core theme of the enabling plan has been “three into one”- replacing or amalgamating the systems used in the three UWS members prior to amalgamation.

Key issues addressed as a part of this strategy included:

• Implementing an enterprise architecture that provides the framework within which systems and services can be developed, delivered and supported;

• Extending this access to both on-campus and off-campus locations in a secure manner;

• Ensuring maximum integration between and across the various applications to reuse data;

During the implementation of this project, Information Technology at UWS must continue to function in an efficient and effective manner. There should be minimal disruption to staff and students and to business operations and processes.

The critical success factors to achieve these requirements are:

• Project plans need to have clear deadlines and responsibilities assigned.

• The project needs strong support from University Executive

• The project needs strong support from the Executive Deans, Heads of Schools and Directors.

• Administrative support needs to be provided once the project reaches implementation phase.

• Timely decisions need to be made on policies, procedures and issues outside the authority of the Project Manager

• There needs to be a robust, explicit and effective communication strategy that allows for clear and frequent communication to all University staff (and students) that need to be involved.

• There needs to be open communication between the Steering Committee, and the sponsor.

The Project Manager needs to have access to the required infrastructure and infrastructure support.

Conclusion:

There is a risk that focus groups may not be widely attended. Establishing strong communication links when inviting staff to attend the focus group sessions will mitigate this. The implementation of a range of modern administrative information systems is fundamental to the provision of consistent and quality administrative support services to staff and students.

Task 2

Definition

A software life cycle model (SLCM) is a representation of the major components of software development work and their interrelationships in a graphical framework that can be easily understood and communicated. Just as the WBS partitions the deliverable into its component parts so the SLCM apportions the work to be done into manageable work units.

Classifying Life Cycle Processes

In planning software development you need to consider the complete exercise as a process. To effectively manage it you need to break it up into component sub processes. Figure 1. A presents the 3 main class of software development process and gives examples of the members of each class.

Figure 1. Software life cycle process classifications.

Project Support Processes are involved with the management of the software development exercise. They are performed throughout the life of the project.

Development Processes embody all work that directly contributes to the development of the project deliverable. They are typically interdependent.

Integral processes are common processes that are performed in the context of more than one development activity. For example, the review process is performed in the context of requirements definition, design and coding.

Describing a Process

Processes are described in terms of a series of work units. Work units are logically related chunks of work. For example, all preliminary design effort is naturally chunked together. Figure 2 describes the components of a work unit.

Figure 2. Components of a work unit.

A work unit is described in terms of:

Work Flow Input/Output. Work flows are the work products that flow from one work unit to the next. For example, in figure 107.1 the design specification flows from the output of the design work unit to the input of the code work unit. Work flows are the deliverables from the work unit. All work units must have a deliverable. The life cycle model should provide detailed descriptions of the format and content of all deliverables.

Entry criteria are the conditions that must exist before a work unit can commence.

Statement of work (SOW). The SOW describes the work to be performed on the work flow inputs to create the outputs.

Exit criteria. The conditions that must exist for the work to be deemed complete.

Table . Examples of entry and exit criteria and statements of work.

Feedback paths are the paths by which work performed in one work unit impacts work either in progress of completed in a preceding work unit.

Implementing feedback paths on your project requires the following procedures:

A procedure to raise issues or defects with baselined deliverables.

A procedure to review issues and approve rework of baselined deliverables.

Allocation of budget for rework in each project phase.

Sequencing Work Units

Figure.4 provides an example of a life cycle model constructed by sequencing work units.

Figure: 4. Life cycle model.

In figure 107.4 examples of workflows are requirements specification and design specification. The work units are Design, Code and Test and the feedback paths carry requirements, design and coding issues.

A project is composed of a set of actions or tasks, which usually have some kind of interdependency. For example, before an axle can be turned, it must first be designed, the metal must be purchased, etc. This type of complex system is much easier to understand through the use of diagrams than through textual description, as actual interconnections between tasks can be shown.

Activity Networks

The Activity Network diagram displays interdependencies between tasks through the use of boxes and arrows. Arrows pointing into a task box come from its predecessor tasks, which must be completed before the task can start. Arrows pointing out of a task box go to its successor tasks, which cannot start until at least this task is complete.

Fig. 1. The Activity Network Diagram

In a network such as this, the points where arrows meet are called nodes. Thus, as there are tasks (or activities) at these points, it is also known as an Activity-on-Node Diagram. It is usually easier to work with than the alternative Activity-on-Arrow Diagram, where the arrows represent tasks.

Fig. 1.1: The Critical Path and Slack

It is possible to have what appears to be a task which takes no time to complete. This is called a checkpoint or milestone, and is usually included in the diagram to highlight an important point in the project.

The Activity Network can be used to identify risk in the plan. Typical areas where there is a danger of the schedule being slipped include:

• Anywhere on the critical path.

• Where there is a long sequence of tasks, each with a single predecessor and successor. Where a task has many predecessors. If any one predecessor task is delayed, then the task will also be delayed.

• When a resource or person that may become unavailable is used in any of the above situations, the risk is compounded.

• Where there are many tasks running at one time, particularly if there are several risky ones. A risk here is that management will not be able to cope with simultaneous failure.

Fig. 3.1 Risks in the Activity Network

Mind Maps

A hand-drawn mind map

A mind map is a diagram used to represent words, ideas, tasks, or other items linked to and arranged radially around a central key word or idea. It is used to generate, visualize, structure, and classify ideas, and as an aid in study, organization, problem solving, decision making, and writing.

It is an image-centered diagram that represents semantic or other connections between portions of information. By presenting these connections in a radial, non-linear graphical manner, A mind map is similar to a semantic network or cognitive map but there are no formal restrictions on the kinds of links used.

The elements are arranged intuitively according to the importance of the concepts and they are organized into groupings, branches, or areas.

Origins

Mind maps (or similar concepts) have been used for centuries for learning, brainstorming, memory, visual thinking, and problem solving by educators, engineers, psychologists, and people in general.

People have been using image-centered radial graphic organization techniques, referred to variably as mental or generic mind maps or spidergrams, for centuries in areas such as engineering, psychology, and education.

The mind map continues to be used in various forms, and for various applications including learning and education (where it is often taught as 'Webs', 'Mind webs', or 'Webbing'), planning, and in engineering diagramming.

When compared with the concept map (which was developed by learning experts in the 1970s) the structure of a mind map is a similar, but simplified, radial by having one central key word.

Uses of mind maps

A mind map is often created around a single word or text, placed in the center, to which associated ideas, words and concepts are added.

Rough mindmap notes taken during a course session

Mind maps have many applications in personal, family, educational, and business situations, including notetaking, brainstorming (wherein ideas are inserted into the map radially around the center node, without the implicit prioritization that comes from hierarchy or sequential arrangements, and wherein grouping and organizing is reserved for later stages), summarizing, revising, and general clarifying of thoughts. One could listen to a lecture.

Mindmaps can be drawn by hand, either as 'rough notes' during a lecture or meeting, for example, or can be more sophisticated in quality. Examples of both are illustrated. There are also a number of software packages available for producing mind maps

Task 3

The image shows the model produced by Bruce Tuckman which describes team development. There are four phases within the model:

• Forming

• Storming

• Norming

• Performing

Forming Storming Norming and Performing

A team development model by Bruce Tuckman that is still relevant today and used by Quest to help teams understand the process they experience when training to become a successful team.

Dr Bruce Tuckman published his Forming Storming Norming Performing model in 1965. The theory is a useful way to explain the development and behaviour process of a team as they embark on a particular team building exercise.

The four stages explained:

Forming - stage 1

When a team comes together for the first time, there is usually an appointed leader. He or she may not actually be suitable for the role as leader at first but here will tend to be a high dependence on the leader for guidance and direction. There will be little agreement on the aims of the team. Individual roles and responsibilities are unclear. Leader must be prepared to answer lots of questions about the team's purpose, objectives and external relationships. Processes are often ignored. The leader will be tested by the individuals.

Storming - stage 2 The group will find it difficult to reach decisions in this stage and there will be much dissention. Individual roles and responsibilities will be fought for. The leader will be tested further. Personality types will come out in individuals some of which may be disliked by other members and first impressions will be formed which may hinder any further performance. The whole team may be caught up in a emotional struggle where some individuals may become disinterested and withdrawn, where others will shine. Compromises may be required to enable progress.

Norming - stage 3

Team members begin to get to know one another better - understanding each others strengths and weaknesses. a new leader may be appointed. There will be clear roles and responsibilities some accepted, others tolerated, The group makes decisions as a whole. The group start to become unified more with a clear aim as to what must be achieved.

Performing - stage 4

This is the stage where the team forms a strategy. Everything is ordered and the team members will know exactly what to do when. Individuals are performing their specific roles within the team and there is a clear focus on what the team is to achieve and huge motivation to get there. The leader will delegate projects and tasks to specific members of the group but will be able to take more of a back seat as the teams are performing in their own right. There may still be some disagreements but there is maturity in the way these are dealt with. The individual relationship issues within the team are also dealt with in a much better way so as to include the whole team and there will be the chance for some interpersonal development

• Oriented roles - Shaper, Implementer, and Completer Finisher

• People-oriented roles - Coordinator, Team worker and Resource Investigator

• Cerebral roles - Plant, Monitor Evaluator and Specialist

Explanation of

Team & Group Reports from BELBIN e-interlace

Candidates' Working Relationships

This function offers advice on the Working Relationship between two people in terms of their Team Roles. The report is not designed to say who will and who will not relate well in general terms, but to suggest what may happen specifically in working relationships in the light of Team-role characteristics. This is termed Team-role Chemistry'.

Overview of Team-Role Profiles

Lists the top Normed Team-Role on the left to bottom team role on the right. Useful to see the overall team/group information at a glance, and if cumulative Observers are different to the Self Perception. Each observer is weighted equally (unlike the Observer Pie Chart). The overall ranking is the calculation of the Self and Cumulative Observers, but is compiled and weighted according to the number of observers.

Team Report (for between 3-15 people)

Allocates team roles to different members of the team. Each team role is allocated only once for a team of 8 or less. Team reports for between 9-15 team members, will perhaps allocate more than one person to each role. There are times when people will not be allocated their top team roles. This is because there has to be a compromise on the basis of team composition. The Specialist role is not allocated in the script, though shown individually (blue) and group average (green) on the graph.

Strong Examples of Team Roles

The "Strong Examples of Team-Roles" finds people who are very high in a certain team role(s) and what are called "good examples of a type". If there are no people selected, then perhaps that particular team does not have a strong example of that type.

Group/Organization Team-Role

This report can be used for any number of people. The script will advise about what the group may encounter based on the top and bottom team role averages.

Most Highly Rated Observer Responses

This list of words in descending order of popularity shows the observer words that were ticked/checked.

Myers- Briggs

The purpose of the Myers-Briggs Type Indicator^® (MBTI) personality inventory is to make the theory of psychological types described by C. G. Jung understandable and useful in people's lives. The essence of the theory is that much seemingly random variation in the behavior is actually quite orderly and consistent, being due to basic differences in the ways individuals prefer to use their perception and judgment.

The identification of basic preferences of each of the four dichotomies specified or implicit in Jung's theory.

The identification and description of the 16 distinctive personality types that result from the interactions among the preferences.”

Excerpted with permission from the MBTI^® Manual: A Guide to the Development and Use of the Myers-Briggs Type Indicator^®

Favorite world: Do you prefer to focus on the outer world or on your own inner world? This is called Extraversion (E) or Introversion (I).

Information: Do you prefer to focus on the basic information you take in or do you prefer to interpret and add meaning? This is called Sensing (S) or Intuition (N).

Decisions: When making decisions, do you prefer to first look at logic and consistency or first look at the people and special circumstances? This is called Thinking (T) or Feeling (F).

Structure: In dealing with the outside world, do you prefer to get things decided or do you prefer to stay open to new information and options? This is called Judging (J) or Perceiving (P).

Your Personality Type: When you decide on your preference in each category, you have your own personality type, which can be expressed as a code with four letters.

The 16 personality types of the Myers-Briggs Type Indicator^® instrument are listed here as they are often shown in what is called a “type table.”

For a description of your MBTI type, place your cursor over the box containing your four-letter type code. You may also wish to browse through all of the 16 type descriptions.

If you do not know your MBTI type, you may wish to take the instrument.

Type tables can also be used to gather and facilitate analysis of information about teams or specific groups of people.

All types are equal: The goal of knowing about personality type is to understand and appreciate differences between people. As all types are equal, there is no best type.

Diagnosing Team Failure

Factors Identifying Six Common Problem Areas &

How do these Factors Affect Team Performance?

• No Trust Between Team Members

When team members don't trust each other or are suspicious of each others motives, the end result is a team that is not cohesive in its approach.

• Ineffective Interaction and Unproductive Team Meetings

All the complexities of team dynamics come to the fore at the meeting. The meeting is one of the most critical aspects of the team process with strategies and innovative solutions to problems emerging during this time.

• Poor Role Clarity

Role clarity is a must in a team situation. When roles are not clearly defined, this can lead to conflict and confusion on tasks.

Losing Focus of Business Objectives

If you don't know where you are heading, how can you get there? At times a team fails because the goals are unclear to the team members.

• Faulty Analysis of Market Conditions and Flawed Company Policies At times a team can fail due to uncertainties in market conditions and an inability to read the signs of change.

• Poor Time Management

A team should plan its goals and activities whilst keeping time constraints and deadlines in mind, otherwise their efficiency level in managing and implementing a task can suffer.

Conclusions on Team Failure

Let's now look at the other side of the coin, success. If success is what the team is after, then what is it that is expected of teams? What should they do to be successful?

• Understand their goals

• Interact, communicate effectively, explore ideas and innovative approaches

• Be loyal, co-operative, willing to share information and lend a helping hand

• Understand market realities and develop a sound strategy

• Keep time frames in mind

• Know their responsibility within the team and focus on results

Task 4

Software Verification & Validation Model

Introduction:

An introduction to ‘Verification & Validation Model' used in improvement of software project development life cycle.

A perfect software product is built when every step is taken with full consideration that ‘A right product is developed in a right manner'. ‘Software Verification & Validation' is one such model, which helps the system designers and test engineers to confirm that a right product is build right way throughout the development process and improve the quality of the software product. ‘Verification & Validation Model' makes it sure that, certain rules are followed at the time of development of a software product and also makes it sure that the product that is developed fulfills the required specifications. This reduces the risk associated with any software project up to certain level by helping in detection and correction of errors and mistakes, which are unknowingly done during the development process.

What is Verification?

The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e. Verification is a process that makes it sure that the software product is developed the right way. The software should confirm to its predefined specifications, as the product development goes through different stages, an analysis is done to ensure that all required specifications are met. Methods and techniques used in the Verification and Validation shall be designed carefully, the planning of which starts right from the beginning of the development process. The Verification part of ‘Verification and Validation Model' comes before Validation, which incorporates Software inspections, reviews, audits, walkthroughs, buddy checks etc. in each phase of verification (every phase of Verification is a phase of the Testing Life Cycle)

During the Verification, the work product (the ready part of the Software being developed and various documentations) is reviewed/examined personally by one ore more persons in order to find and point out the defects in it. This process helps in prevention of potential bugs, which may cause in failure of the project. Few terms involved in Verification:

Inspection: Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the documents and work product during various phases of the product development life cycle. The work product and related documents are presented in front of the inspection team, the member of which carry different interpretations of the presentation.

Walkthroughs: Walkthrough can be considered same as inspection without formal preparation (of any presentation or documentations). During the walkthrough meeting, the presenter/author introduces the material to all the participants in order to make them familiar with it.

Buddy Checks:

This is the simplest type of review activity used to find out bugs in a work product during the verification. In buddy check, one person goes through the documents prepared by another person in order to find out if that person has made mistake(s)

What is Validation?

Validation is a process of finding out if the product being built is right? i.e. whatever the software product is being developed, it should do what the user expects it to do. The software product should functionally do what it is supposed to, it should satisfy all the functional requirements set by the user. Validation is done during or at the end of the development process in order to determine whether the product satisfies specified requirements.

Validation and Verification processes go hand in hand, but visibly Validation process starts after Verification process ends (after coding of the product ends). Each Verification activity (such as Requirement Specification Verification, Functional design Verification etc.) has its corresponding Validation activity (such as Functional Validation/Testing, Code Validation/Testing, System/Integration Validation etc.).

Terms used in Validation process:

Code Validation/Testing:

Developers as well as testers do the code validation. Unit Code Validation or Unit Testing is a type of testing, which the developers conduct in order to find out any bug in the code unit/module developed by them.

Integration Validation/Testing:

Integration testing is carried out in order to find out if different (two or more) units/modules co-ordinate properly.

Functional Validation/Testing:

This type of testing is carried out in order to find if the system meets the functional requirements. In this type of testing, the system is validated for its functional behavior. Functional testing does not deal with internal coding of the project, in stead, it checks if the system behaves as per the expectations. User Acceptance Testing or System Validation:

In this type of testing, the developed product is handed over to the user/paid testers in order to test it in real time scenario. The product is validated to find out if it works according to the system specifications and satisfies all the user requirements.

Terminology

Verification is a quality process that is used to evaluate whether or not a product, service, or system complies with a regulation, specification, or conditions imposed at the start of a development phase. Verification can be in development, scale-up, or production. This is often an internal process.

Validation is the process of establishing documented evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements. This often involves acceptance and suitability with external customers.

Dynamic verification (Test,Experimentation)

Dynamic verification is performed during the execution of software, and dynamically checks its behaviour; it is commonly known as the Test phase. Verification is a Review Process. Depending on the scope of tests, we can categorize them in three families:

• Test in the small: a test that checks a single function or class (Unit test)

• Test in the large: a test that checks a group of classes, such as

• Module test (a single module)

• Integration test (more than one module)

• System test (the entire system)

• Acceptance test: a formal test defined to check acceptance criteria for a software

• Functional test

• Non functional test (performance, stress test)

Software verification is often confused with software validation. The difference between 'verification and validation:

• Software verification asks the question, "Are we building the product right?"; that is, does the software conform to its specification.

• Software validation asks the question, "Are we building the right product?"; that is, is the software doing what the user really requires.

The aim of software verification is to find the errors introduced by an activity, i.e. check if the product of the activity is as correct as it was at the beginning of the activity.

The aim of software validation is to declare whether the product of an activity is indeed what is expected, i.e. the activity extended the product successfully.

Static verification (Analysis)

Static verification is the process of checking that software meets requirements by doing a physical inspection of it. For example:

• Code conventions verification

• Bad practices detection

• Software metrics calculation

• Formal verification

Reference & Bibliography:

• http://www.sei.cmu.edu/cmmi/faq/tech-faq.html

• www.geekinterview.com/question_details/1866

• doi.ieeecomputersociety.org/

• www.MindMappingStrategies.com

• www.levela.com

• www.waa-inc.com

• www.syque.com

• www.chambers.com.au

• www.jcu.edu.au

• www.fao.org

• 12manage.com

• www.wuest-thegreatoutdoors.co.uk

• www.jiscinfonet.ac.uk

• www.tembuildingportal.com

• www.myersbriggs.org

• en.wikipedia.org/wiki/Wikipedia

• ww.sei.cmu.edu

• Pdf file from www.belbin.com

Sign up and be the first to receive our latest offers: