Project Plan Templates

Project Design Requirements-Deep Dig

Project Design Requirements-Deep Dig

What is a Project with out Requirements?

1. Missed opportunity
2. Wishful thinking
3. Risky business
4. All of the above

Every project should be based on a sound specification of requirements (functional, technical, business and process). Within the project environment, requirements serve three key purposes:

• Requirements form the basis for project deliverables, specifying operational needs and functionality.
• Requirements establish a consensus and common ground amongst project stakeholders and participants.
• Requirements quantify expectations into specific results that can be given form and substance.

Projects must be designed to deliver effective business and technical solutions. To meet that goal, every project must also begin with an approved requirements specification. But, before project requirements can be selected and approved, they must be collected, culled and defined. Considering the complex nature of technology projects, requirements are typically multi-faceted and often elusive, subject to opinion and bias. As such, the requirements collection process must reflect these realities to identify requirements at all levels and perceptions.

Within the project environment, requirements may vary by project type and circumstances, but can be quantified according to four primary categories:

• Functional Requirements: to determine the appearance, features and operational functionality of the project deliverables.
• Technical Requirements: to determine the technical elements of the project deliverables, including design specifications, operational requirements, platform compatibility, capacity and performance requirements.
• Business Requirements: to determine overall project goals and vision, including business goals, objectives, productivity expectations, return on investment and payback requirements.
• Process Requirements: to determine the project process requirements, governing the way that the project is to be managed, including project management policies, procedures and best practices.

The requirements management process:

Project Manager / Engineer

The POME Project Management Methodology is designed to guide project managers in the amount of project management tasks required to be completed for a given project.

The criteria for the applicable project management tasks is based on the following:-

project team's previous experience

the project size and duration

other risk associated with the project (eg remote location, new products, contractual arrangements etc).

The Methodology is also designed to be scalable such that the bare minimum effort can be applied to ensure cost competitive delivery of the project.

The Qualification of Methodology tool allows this determination to be made.

1

Project Manager / Engineer

Using the Qualification of Methodology tool, determine the project management tasks required for the project. Mandatory project management tasks are indicated by a "tick", and other project management tasks are applicable as nominated on the tool (depending upon the project criteria).

Note that if certain tasks (even mandatory tasks) are not relevant for the project, include this and any associated comments on the tool. These deleted requirements do require sign-off by the Team Leader or Operations Manager.

2

Project Manager / Engineer

The Qualification of Methodology tool must be reviewed and signed off by your Team Leader or Operations Manager.

1

Project Manager / Engineer

Following the completion of the Methodology Qualification Tool, the level of project management tasks has been determined.

2

Project Manager / Engineer

With the Methodology Qualification in mind, review the following aspects of the project to ensure the planned tasks all add value in achieving the project goals in the most efficient manner:

Scope

Products

Project team experience

Risks

Leadtime

New applications, requirements or products

Customer relationship

Location

Subcontractors & suppliers.

3

Project Manager / Engineer

Using the Project Plan template, create the Project Plan for the project ensuring that the Plan contains project specific information.

As you go through the process of requirements identification and analysis, you need to consider the types of requirements that must be defined, as well as the various individuals involved in the requirements process. Since requirements define deliverables and build consensus, it essential that all key stakeholders are involved in the requirements process as needed, whether that involvement includes identification, review or approval.

Step One: Seek Requirements

Obtain a Requirements Statement from the appropriate project participants, in order to get a "first-hand" perspective of project requirements from a stakeholder point of view.

• Functional Requirements: Provided by end-users/customers.
• Technical Requirements: Provided by technical staff.
• Business Requirements: Provided by end-users & management.
• Process Requirements: Provided by IT and project staff.

Step Two: Validate Requirements

Evaluate and validate requirements against business needs, technical possibilities, internal capabilities, alternatives, and budget realities.

• Are the requirements realistic?
• Are the requirements attainable?
• Are the requirements consistent with technology best practices, business goals, budgets and objectives?
• Are the requirements sufficient to act?
• If fulfilled, will these requirements meet a viable need, or will they create new needs and problems?

Step Three: Restate Requirements

Restate the requirements in specific terms upon which further action can be taken. This restatement should phrase requirements in terms of the project deliverable, demonstrating to the project customer that their requirements have been understood and that results can be produced.

Step Four: Analyze Risks

Identify the risks and assumptions upon which these requirements are based.

Step Five: Seek Acceptance & Approval

Seek acceptance and approval of your restatement of requirements. This acceptance and approval should be obtained from all relevant project stakeholders and participants.

Step Six: Manage Change

Establish change request procedures that will allow requirements to change as the project develops, and as needs and circumstances dictate. Requirements changes should be kept to a minimum, and only as needed. In order to ensure that requirements changes are evaluated appropriately, change requests should account for the following:

• The individual requesting the change.
• The specifics of the change.
• The reason for the change.
• The likely impact on the project.
• Task changes required (by task, date and activities involved).
• The costs involved.
• Steps for review and approval.
• Criteria for change request acceptance or rejection.

Requirements Collection Methods:

Interviews: "Face to face" interviews with one or more project stakeholders. These "requirements" interviews can occur as one-on-one meetings or group brainstorming sessions. Tip: Interviews are most appropriate for projects with a small number of "requirements contributors", where requirements must be gathered from a select, concentrated group.

Surveys: Documented questions (on paper or in electronic format) designed to collect "written" requirements feedback from one or more project stakeholders. Tip: Surveys are most appropriate for projects with a large number of "requirements contributors" where requirements must be gathered from a diverse group.

Observation: Direct "interaction" with project customers (i.e. end-users) to observe and identify requirements based on current workflows and practices. Tip: Observation is most appropriate for "performance or productivity improvement" projects where problems must be translated into actionable requirements.

In practical application, most projects will involve some combination of these various methods in order to collect a full set of useful requirements.

Requirements Collection Techniques:

Good questions produce good answers?.

• Open Ended Questions: Open ended questions require more than a "yes" or "no" response. As such, open ended questions can be used to provoke broad analysis and discussion (to uncover opportunity and potential).

Example: What type of reports will you require from the new system?

• Closed Ended Questions: Closed ended questions require only a "yes" or "no" response. As such, closed ended questions can be used to validate previously identified requirements assumptions.

Example: Do you require a monthly account summary report?

• Hypotheticals: Hypothetical questions present a specific situation or circumstance for which reasoned feedback is required. Hypotheticals can be used to establish justifications and priorities.

Example: If the system produced monthly account summary reports, how would those reports be used?

• Strawman Statements: Strawman statements present specific, pre-defined requirements "items" to be ranked in order of priority by one or more project stakeholders. Strawman statements can be used to quickly validate requirements assumptions, and to establish priorities amongst multiple sets of requirements.

Example: Rank the following reports in order of priority (1 - 3):

___ Daily Accounts Summary

___ Weekly Accounts Summary

___ Monthly Accounts Summary

Getting Started......

Before the requirements collection process begins, the following issues and questions must be addressed:

Participants: Who should participate in the requirements specification process? Requirements "contributors" should be selected according to project role, deliverables "stake", expertise, experience, and internal organizational issues.

Timing and Scope: How much time is available for the requirements collection process considering project scope and the number of participants? Requirements collection "timing and scope" will determine the data collection methods to be used.

Goals: What are your requirements collection goals? Do you need to validate and verify pre-defined requirements assumptions, or do you need to gather requirements feedback at the broadest levels possible? These goals and needs will help to determine your selected requirements techniques, including questions "content and format"/

Concluded Note:

Once requirements data has been collected, analyzed and finalized, the resulting "requirements statement" should be verified and validated to ensure that the specified requirements match actual needs and intent. As such, the Requirements Statement should be formally approved before project work begins. Considering the role that requirements play within any project, the requirements process should be in effect from the start of the project, through closure. At the start of the project, requirements define deliverables. As the project proceeds, requirements must remain in alignment with changing project circumstances, and as such requirements must be controlled and managed. At the end of a project, the quality of the requirements process must be evaluated as part of any post project review process.

Design Methodology

While the conceptual design process may be formal or informal, it can be characterized by a series of actions: formulation, analysis, search, decision, specification, and modification. However, at the early stage in the development of a new project, these actions are highly interactive as illustrated in the below Figure Many iterations of redesign are expected to refine the functional requirements, design concepts and financial constraints, even though the analytic tools applied to the solution of the problem at this stage may be very crude.

Figure: Conceptual Design Process

The series of actions taken in the conceptual design process may be described as follows:

• Formulation refers to the definition or description of a design problem in broad terms through the synthesis of ideas describing alternative facilities.
• Analysis refines the problem definition or description by separating important from peripheral information and by pulling together the essential detail. Interpretation and prediction are usually required as part of the analysis.
• Search involves gathering a set of potential solutions for performing the specified functions and satisfying the user requirements.
• Decision means that each of the potential solutions is evaluated and compared to the alternatives until the best solution is obtained.
• Specification is to describe the chosen solution in a form which contains enough detail for implementation.
• Modification refers to the change in the solution or re-designs if the solution is found to be wanting or if new information is discovered in the process of design.

As the project moves from conceptual planning to detailed design, the design process becomes more formal. In general, the actions of formulation, analysis, search, decision, specification and modification still hold, but they represent specific steps with less random interactions in detailed design. The design methodology thus formalized can be applied to a variety of design problems.

---

GAUTAM KOPPALA, With over a decade, track record of successful leadership, excellent results through strategic skills in driving revenue and profit growth. Demonstrated ability to identify and trouble shoot critical issues impacting productivity, cost, distribution, marketing, Strategic positioning, sales and financial operations, with innate ability to build and maintain strong client relationships in operations. Expert in distilling and managing processes, enhancing internal structures, and promoting multi-skilled team competencies via nurturing mentorship and inspirational leadership. Engagements have spanned operational, strategic, technological and change management roles. Academically, I am a cum laude graduate with a Bachelor of Technology degree in Electrical and Electronics Engineering (B-Tech E.E.E.) and a post graduate in Masters in Human Resources Management (M.H.R.M.) and Masters of Foreign Trade (M.F.T.). As you will see my Post Graduation's were been studied part-time, as well as working full-time as an Engineer. I feel that this demonstrates my ability to maintain dedication, motivation and enthusiasm for a project management over a long period of time. In addition, balancing full-time work with study has perfected my time-management and organizational skills. I believe that my college degrees and gamut certifications in combination with my extensive broad-based work experience along with my drive, resourcefulness and determination, would make me an excellent candidate for a senior management position with any company. Highlights of my background include Operations related Commercial, Supply chain, Sales with a magnificent experience in Project management, technically oriented towards Automation and Security Systems in Industrial and Building sectors. Presently, writing a book on Projects and Operations Management (comprise of 12 volumes, 6K pages), and awaited for the reputed publications. These books can be checked in Google books and other search engines too.

Article Source: ArticlesBase.com