Software Project Requirement and Team Requirement Model

25
Software Project Requirements with Project Team Member Requirement A MODEL FOR ALIGNING KAUSHAL MISHRA (MCA )

Transcript of Software Project Requirement and Team Requirement Model

Page 1: Software Project Requirement and  Team Requirement  Model

Software Project Requirements with Project Team Member Requirement

A MODEL FOR ALIGNING

KAUSHAL MISHRA (MCA ) SRMGPC ,LUCKNOW

Page 2: Software Project Requirement and  Team Requirement  Model

Introduction

What are the root causes that lead some project teams to operate well, while others struggle?

Underperforming project teams may result from a weak change management plan, lack of talent on the project team, or insufficient stakeholder support, among other factors.

Many IT projects today have a project charter. Key components of a charter include the project scope, timeline, budget, approach and expected benefits.

All individuals related to the project want the best for the organization. However, when they see the project charter through their own prism, they may see the scope, the benefits and the approach quite differently. This is why it is critical to align early and often.

Page 3: Software Project Requirement and  Team Requirement  Model

What does a high-performance project team look like?

Page 4: Software Project Requirement and  Team Requirement  Model

Project Roles and Responsibilities

Projects of different sizes have different needs for how the people are organized. In a small project, little organization structure is needed. There might be a primary sponsor, project manager and a project team.

Analyst : The Analyst is responsible for ensuring that the requirements of the business clients are captured and documented correctly before a solution is developed and implemented.

Change Control Board :The Change Control Board is usually made up of a group of decision makers authorized to accept changes to the projects requirements, budget, and timelines

Client: This is the people (or groups) that are the direct beneficiaries of a project or service. They are the people for whom the project is being undertaken.

Client Project Manager : If the project is large enough, the business client may have a primary contact that is designated as a comparable project manager for work on the client side.

Page 5: Software Project Requirement and  Team Requirement  Model

Project Roles and Responsibilities Database Administrator: A Database Administrator is a specialist that models, designs and creates the databases and

tables used by a software solution Designer: The designer is responsible for understanding the business requirements and designing a solution that will

meet the software needs. Developer: The Developer is responsible for the actual building of the solution. Project Manager: This is the person with authority to manage a project. This includes leading the planning and the

development of all project deliverables. The project manager is responsible for managing the budget and schedule and all project management procedures (scope management, issues management, risk management, etc.)

Quality Manager : On a large project, quality management could take up a large amount of project management time. Sponsor : This is the person who has ultimate authority over the project. The Sponsor provides project funding,

resolves issues and scope changes, approves major deliverables and provides high-level direction. Stakeholder : These are the specific people or groups who have a stake, or an interest, in the outcome of the project. Suppliers / Vendors , Tester , Users

Page 6: Software Project Requirement and  Team Requirement  Model

Project Roles and Responsibilities

Project Team : The project team consists of the full-time and part-time resources assigned to work on the deliverables of the project. This includes the analysts, designers, programmers, etc. They are responsible for: Understanding the work to be completed. Planning the assigned activities in more detail if needed. Completing assigned work within the budget, timeline and quality expectations. Informing the project manager of issues, scope changes, risk and quality concerns. Proactively communicating status and managing expectations.

Page 7: Software Project Requirement and  Team Requirement  Model

How to Put together a high performance Team

Page 8: Software Project Requirement and  Team Requirement  Model

Project Team Requirment

In most cases, an organization’s most valuable asset is its people. The same is true for project teams. Project success generally depends on individual talent, as well as team performance. Highly engaged and motivated teams are often more likely to perform at a high level and achieve their objectives. Team members know each other well and understand everyone's strengths and weaknesses. They genuinely respect and care about each other. They believe in the organization’s mission and the projects objectives. They celebrate successes and learn from failures.

Page 9: Software Project Requirement and  Team Requirement  Model

Provide High-Quality Leadership

Establish your team’s objectives and purpose – It’s important to verify that all team members know exactly what target they are aiming for and why it’s important to both the organization and the team. People may be more likely to work toward a common goal when they clearly understand its meaning and their contribution.

Establish a few rules – You can help build trust when you communicate what’s expected. It’s also generally a good idea to plan ahead in order to manage potential conflicts in a positive way.

Demonstrate trust – Allow people to take risks, experience failures and learn from their mistakes. Encourage creativity . You shouldn’t expect team members to put trust in you if you can’t first demonstrate that you trust them.

Require accountability – Regularly assess both team and individual performance. Deal with issues immediately by enforcing the established rules. Be sure to offer criticism constructively and privately. Without accountability, rules may be ignored, projects derailed and leaders may not respected.

Demonstrate your leadership – Model the work ethic, honesty, and level of communication and cooperation you expect. Show team members what success looks like, and they may be inspired to follow you.

Page 10: Software Project Requirement and  Team Requirement  Model

Recognize and Reward

People often like to be appreciated for a job well done. As a project leader, it's important to recognize team members when they meet important deadlines or achieve significant milestones. Praise from a leader can make team members feel appreciated, and may inspire the entire team to keep working toward the goal. However, keep in mind that not everyone may share the same enthusiasm for the spotlight. When you truly know your team well, you'll learn their preferences.

Page 11: Software Project Requirement and  Team Requirement  Model

Handle Delays Professionally

Work interruptions, technical troubles, additional responsibilities and unforeseen circumstances can delay a project. While they may be normal and expected in business, it doesn’t make missing a deadline any easier to swallow. Leadership is often judged by how people handle obstacles and delays, so make sure to do it professionally.

Start by evaluating the severity of the problem and remember that not every delay is a catastrophe. Next, assess how the delay may affect other aspects of the project, and what resources are available to shift to the problem. Finally, engage team members on finding and implementing the most effective solution. Also, make sure to keep appropriate stakeholders informed of the delay while providing an appropriate solution.

High-performing project teams can help make a project manager’s life easier. Start building your team by following these tips for improving project team performance. They're easy to implement and can pay off in a “dream team” that may help make projects more successful.

Page 12: Software Project Requirement and  Team Requirement  Model

Software Project Requirement

The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product

Requirement Engineering The process to gather the software requirements from client, analyze and document them is known as

requirement engineering. The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System

Requirements Specification’ document.

Page 13: Software Project Requirement and  Team Requirement  Model

Requirement Engineering Process

It is a four step process, which includes –

Feasibility Study Requirement Gathering Software Requirement Specification Software Requirement Validation

Let us see the process briefly -

Page 14: Software Project Requirement and  Team Requirement  Model

Feasibility study

This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.

Page 15: Software Project Requirement and  Team Requirement  Model

Requirement Gathering and SRS

If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

Software Requirement SpecificationSRS is a document created by system analyst after the requirements are collected from various stakeholders.SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

Page 16: Software Project Requirement and  Team Requirement  Model

Software Requirement Specification

Requirements can be checked against following conditions -

If they can be practically implemented If they are valid and as per functionality and domain of software If there are any ambiguities If they are complete

Page 17: Software Project Requirement and  Team Requirement  Model

Requirement elicitation process Requirements gathering - The developers discuss with the client and end users and know their expectations from the

software. Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency

and convenience. Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various

stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised . The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.

Documentation - All formal & informal, functional and non-functional requirements are documented and made available for next phase processing.

Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development.

Page 18: Software Project Requirement and  Team Requirement  Model

Requirement Elicitation Techniques

There are various ways to discover requirements

Interviews:

Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly (confidently).

Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased.

Oral interviews

Written interviews

One-to-one interviews which are held between two persons across the table.

Surveys Organization may conduct surveys among various stakeholders by querying about their expectation and requirements

from the upcoming system.

Page 19: Software Project Requirement and  Team Requirement  Model

Requirement Elicitation Techniques

Questionnaires: A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to

answer, which are collected and compiled

Brainstorming: An informal debate is held among various stakeholders and all their inputs are recorded for further requirements

analysis.

Observation: Team of experts visit the client’s organization or workplace. They observe the actual working of the existing installed

systems. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software.

Page 20: Software Project Requirement and  Team Requirement  Model

Aligning Modal

Typically, alignment is required on three levels:

Sponsors and stakeholders—around the future state vision. Management—around a plan that can be executed. Project team—around priorities and tasks at hand.

Page 21: Software Project Requirement and  Team Requirement  Model

Sponsor and Stakeholder Alignment

Most executives feel that they see things the same way, especially when it comes to decisions that they made together. It is true that most projects are budgeted and start with consent from all appropriate executives. But does consent mean alignment? In reality, it’s likely that each executive wound up (tension) with their own unique vision of what will occur after the project is complete, and what it will take to successfully execute the project.

It is hard to convince executives to meet repeatedly to understand the changes that can push a project off target and to align their resources to the project goals. But this is the only way to stay on track and avoid wasting time on the rework that must will be required if team members take the project towards the misaligned future state visions in their department leads’ heads.

Page 22: Software Project Requirement and  Team Requirement  Model

Management Alignment

Middle management is cynical(selfish). They have seen these projects come and go. In fact, they say, we have more projects than we can keep track of right now. Yet, without a firm belief from middle management that a given project can and will be completed, you can count only on one thing—apathy( Nutral).

It may be tedious(Boring), but it’s well worth the effort to gather all relevant data that could impact the project’s success early on. This includes concerns, dependencies, vacations and other availability information. Chances are, some of that information is relevant to the project, some of it is good to know, and some of it is just fear of change. In all three cases, you want to hear it out and account for it .

Once the project plan has been adjusted to account for relevant data, people start believing that this is a real plan and you are not just going through the motions. After all, they have no more excuses to keep it from happening.

Page 23: Software Project Requirement and  Team Requirement  Model

Project Team Alignment

Most project teams consist of a core team (full-time participants) and an extended team (part-time participants). All of the members of the extended team and many of the core team members likely have other responsibilities in the organization, perhaps participating on other project teams. Not only are team members often distracted, but they each also have their own opinions about how the project should be conducted. It is very hard for a team to work in a coordinated fashion when each member has their own idea of how a given activity should be executed and their role in it.

There are many ways to align a project team around the approach: training the team in the methodology that is being used, team-building exercises, offsite workshops, communication programs, etc. All of these take time and effort, but they are well worth it.

**********

Page 24: Software Project Requirement and  Team Requirement  Model

References

1. Abraic.in (Mikhail Papovsky @mpapov)

Founder and CEO of Abraic, Inc. Dedicated to improving the outcomes of IT investments.

2. http://www.lifecyclestep.com/open/408.0LifecycleRoles.html

(408.0 Project Roles and Responsibilities)

3. Reference paper : Robert Hans Tshwane University of Technology, Pretoria, South Africa [email protected]

Page 25: Software Project Requirement and  Team Requirement  Model

Presented By – KAUSHAL MISHRA