0% found this document useful (0 votes)
229 views

Management Spectrum

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
229 views

Management Spectrum

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

The management spectrum:

For properly building a product, there’s a very important concept that we all should know in
software project planning while developing a product. There are 4 critical components in
software project planning which are known as the 4P’s namely: people, product, process, and
project.

The People

The most important component of a product and its successful implementation is human
resources. In building a proper product, a well-managed team with clear-cut roles defined
for each person/team will lead to the success of the product. We need to have a good team
in order to save our time, cost, and effort. Some assigned roles in software project
planning are project manager, team leaders, stakeholders, analysts, and other IT
professionals. Managing people successfully is a tricky process which a good project
manager can do.

The Stakeholders -The software process is populated by stakeholders who can be


categorized into one of five constituencies:

1. Senior managers - Who define the business issues that often have a significant
influence on the project
2. Project (technical) managers - Who must plan, motivate, organize, and control the
practitioners who do software work.
3. Practitioners - Who deliver the technical skills that are necessary to engineer a product
or application
4. Customers -who specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome.
5. End users - Who interact with the software once it is released for production use.
Team Leaders – MOI model of Leadership
1. Motivation - The ability to encourage (by “push or pull”) technical people to produce
to their best ability.
2. Organization. - The ability to mold existing processes (or invent new ones) that will
enable the initial concept to be translated into a final product.
3. Ideas or innovation. - The ability to encourage people to create and feel creative even
when they must work within bounds established for a particular software product or
application.

Another view of the characteristics that define an effective project manager emphasizes
four key traits:
 Problem solving. - An effective software project manager can diagnose the technical
and organizational issues that are most relevant, systematically structure a solution or
properly motivate other practitioners to develop the solution, apply lessons learned from
past projects to new situations, and -remain flexible enough to change direction if initial
attempts at problem solution are fruitless.
 Managerial identity. - A good project manager must take charge of the project. She
must have the confidence to assume control when necessary and the assurance to allow
good technical people to follow their instincts.
 Achievement. -A competent manager must reward initiative and accomplishment to
optimize the productivity of a project team. She must demonstrate through her own
actions that controlled risk taking will not be punished.
 Influence and team building. - An effective project manager must be able to “read”
people; she must be able to understand verbal and nonverbal signals and react to the needs
of the people sending these signals. The manager must remain under control in high-stress
situations.

The Product
 Before a project can be planned, the product objectives and scope should be
established, alternative solutions should be considered, and technical and management
constraints should be identified.
 Without this information, it is impossible to define reasonable (and accurate) estimates
of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a
manageable project schedule that provides a meaningful indication of progress.
 The software developer and customer must meet to define product objectives and
scope. In many cases, this activity begins as part of the system engineering or business
process engineering and continues as the first step in software requirements analysis.
 The objectives must identify the overall goals for the product (from the customer’s
point of view) without considering how these goals will be achieved.
 The scope identifies the primary data, functions and behaviors that characterize
the product, and more importantly it attempts to bound these characteristics in a
quantitative manner.
 Once the product objectives and scope are understood, alternative solutions must be
considered. The alternatives for this enable managers and practitioners to select a
“best” approach, given the constraints imposed by delivery deadlines, budgetary
restrictions, personnel availability, technical interfaces, and myriad other factors. The
product dimensions include software scope, context, information objectives and
performance.
 The product development also depends on problem decomposition which includes
partitioning or problem elaboration and the focus on functionality to be delivered and
the process used to deliver it.

Problem Decomposition

 Problem decomposition, sometimes called partitioning or problem elaboration, is an


activity that sits at the core of software requirements analysis.
 During the scoping activity no attempt is made to fully decompose the problem.
Rather, decomposition is applied in two major areas: (1) the functionality that must be
delivered and (2) the process that will be used to deliver it.
 Human beings tend to apply a divide and conquer strategy when they are confronted
with a complex problems. Stated simply, a complex problem is partitioned into smaller
problems that are more manageable. This is the strategy that applies as project
planning begins. Software functions, described in the statement of scope, are evaluated
and refined to provide more detail prior to the beginning of estimation.

THE PROCESS

 A software process provides the framework from which a comprehensive plan for
software development can be established.
 A small number of framework activities are applicable to all software projects,
regardless of their size or complexity.
 A number of different task sets namely tasks milestones, work products, and quality
assurance points enable the framework activities to be adapted to the characteristics of
the software project and the requirements of the project team.
 Finally, umbrella activities such as software quality assurance, software configuration
management, and measurement overlay the process model. Umbrella activities are
independent of any one framework activity and occur throughout the process. The
umbrella activities include quality and configuration management.
 The frame work activities include customer communication, planning, risk analysis,
engineering, construction and release and finally customer evaluation.
Process Considerations

The Process model chosen must be appropriate for the customers, developers and the
characteristics of the product which include project development environment and the project
planning begins with melding the product and the process. Moreover, each function to be
engineered must pass though the set of framework activities defined for a software organization.
Work tasks may vary but the common process framework (CPF) is invariant (e.g. size does not
matter). Therefore, the software engineer’s task is to estimate the resources required to move
each function though the framework activities to produce each work product.

THE PROJECT

After conducting the project, the project must be controlled by perfect monitoring. In order to
avoid project failure, a software project manager and the software engineers who build the
product must avoid a set of common warning signs, understand the critical success factors that
lead to good project management, and develop a commonsense approach for planning,
monitoring and controlling the project.
According to the 90/10 rule, 90% of the effort on project to accomplish 10% of the work.
Therefore, it is necessary to manage the project by performing the following:

1. Start on the right foot. This is accomplished by working hard (very hard) to understand
the problem that is to be solved and then setting realistic objects and expectations for everyone
who will be involved in the project. It is reinforced by building the right team and giving the
team the autonomy, authority, and technology needed to do the job.

2. Maintain momentum. Many projects get off to a good start and then slowly disintegrate.
To maintain momentum, the project manager must provide incentives to keep turnover of
personnel to an absolute minimum, the team should emphasize quality in every task it performs,
and senior management should do everything possible to stay out of the team’s way.

3. Track progress. For a software project, progress is tracked as work products (e.g.,
specifications, source code, sets of test cases) are produced and approved (using formal technical
reviews) as part of a quality assurance activity. In addition, software process and project
measures can be collected and used to assess progress against averages developed for the
software development organization.

4. Make smart decisions. In essence, the decisions of the project manager and the software team
should be to “keep it simple.” Whenever possible, decide to use commercial off-the-shelf
software or existing software components, decide to avoid custom interfaces when standard
approaches are available, decide to identify and then avoid obvious risks, and decide to allocate
more time than you think is needed to complex or risky tasks.
5. Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons
learned for each project. Evaluate the planned and actual schedules, collect and analyze software
project metrics, get feedback from team members and customers, and record findings in written
form.

Finally, it is necessary to follow the W5HH Principles listed below to Why is the system being
developed?

1. Why is the system being developed?


o Purpose: This question addresses the underlying business need or problem that
the software aims to solve. It ensures that all stakeholders understand the rationale
behind the project.
o Importance: Clarifying the "why" helps in validating whether the investment in
terms of people, time, and money is justified. It aligns the project with business
goals and ensures that it contributes value to the organization.
2. What will be done?
o Purpose: This question defines the scope of the project by outlining the tasks and
deliverables.
o Importance: Establishing what will be done helps in creating a clear plan of
action. It sets expectations for the project team and stakeholders, ensuring
everyone knows what the end product will encompass.
3. When will it be done?
o Purpose: This question is about scheduling the project, including timelines for
tasks and milestones.
o Importance: A well-defined schedule is crucial for tracking progress, managing
deadlines, and ensuring timely delivery. It helps in resource planning and setting
realistic timelines for completion.
4. Who is responsible for a function?
o Purpose: This question identifies the roles and responsibilities of each team
member and stakeholder.
o Importance: Clear delineation of responsibilities helps in accountability and
ensures that everyone knows their specific duties. It facilitates coordination and
minimizes confusion or overlap in roles.
5. Where are they organizationally located?
o Purpose: This question addresses the organizational structure and the positioning
of team members and stakeholders.
o Importance: Understanding the organizational location of responsibilities
ensures effective communication and collaboration. It also highlights the
involvement of external stakeholders like customers or users, who play a critical
role in the project's success.
6. How will the job be done technically and managerially?
o Purpose: This question focuses on the methods, technologies, and management
strategies that will be used to execute the project.
oImportance: Defining the technical and managerial approach ensures that the
project has a solid foundation and a clear path to follow. It helps in risk
management, quality assurance, and adherence to best practices.
7. How much of each resource is needed?
o Purpose: This question is about estimating the resources required, including time,
money, personnel, and tools.
o Importance: Accurate resource estimation is essential for budgeting, resource
allocation, and project feasibility. It ensures that the project has sufficient
resources to meet its goals without unnecessary overspending.

By addressing these W5HH principles, a project can be better planned, managed, and executed,
increasing the likelihood of its success.

Bohem’s W5HH principle is applicable regardless of the size or complexity of a software


project. The questions noted provide an excellent planning outline for the project manager and
the software team.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy