INITIATING A SOFTWARE PROJECT

 Projects, big and small, have to be initiated.

 All initiation really means is that everyone acknowledges that
the project has a purpose (and that everyone agrees on what
that purpose is)
 The purpose: to solve a problem, to grasp an opportunity, or
to meet demand for a new piece of software.
 Software projects, all software projects, have one thing in
common: They attempt to provide something for someone
else, whether it’s the organization or the customer.
 The goal, from a project manager’s perspective, is to solve the
problem to satisfy the demand.
IDENTIFYING THE PROJECT PURPOSE
 Successful projects, and, by default, successful project
managers, have to start by ironing out a few details. Make
sure these questions are asked and successfully answered:
 Why is the project being initiated? You first have to know
the project purpose.
 Does everyone agree on this purpose and goals? There
must be consensus on what the project will create. There
must be consensus on the goals of the project.
 If not, you can count on trouble before the project is
complete.
IDENTIFYING THE PROJECT PURPOSE
 The project purpose is just a fancy way of understanding
the background of why the project is being initiated. If
you don’t have enough background information,
 you won’t be able to ask the right questions to create a
solution that solves the problem, grabs the opportunity,
or improves the organization.
 Your fundamental purpose, at this point in the project life
cycle, is to understand why the project is being initiated.
 But another crucial element to successful project
management is to be in tune with the structure of your
organization.
TALKING TO THE STAKEHOLDERS
 More the information we have about project goals at
initiation, better position we are in to achieve project
goals.

 Stakeholders, from customers to senior management, will

have different concepts about what signifies that a project
is complete.

 We need to know what their expectations are so we can

reach the project completion with few surprises.
FIVE QUESTIONS FOR STAKEHOLDERS

 What are the factors for completion?

 What is the goal of this project?

 What are the areas of the organization that this

project will affect?

 What is the project priority?

 What is the accepted range of variance?

ORGANISATIONAL LEVELS
DISCUSSING WITH THE EXECUTIVES
Questions we need to ask executives, assuming we’ll be
interacting with them:
 What are the factors for project success?
 What’s your vision for the project result?
 What’s more important, time or budget?
 What risks do you anticipate for this project’s success
Sometimes there is a disconnect between a project’s stated
purpose and its actual purpose.
The more detailed information from the executives makes it
easy to identify this disconnect early and straighten it out.
PLAYING WITH FUNCTIONAL MANAGEMENT
Questions we’ll need to ask functional managers:
 What are the factors for project success?
 Are there scheduling issues that will affect the project’s
end date?
 What resources are available for the software creation?
 What departments and customers will need to interact?
 How will the project team be assembled?
 Do you have a preset budget in mind for the project?
 What risks do you see for this project?
CHATTING WITH OPERATIONS
Questions we need to ask from people in operations:
 What are the factors for project success?
 How will the software be used?
 What other software projects are you working on now?
 What immediate risks do you see in the project?
 Who has the experience to get this done?
 Do we need training to create this software?
 What areas of the project are you dreading?
REACHING PROJECT CONSENSUS
 Understanding the project purpose during initiation is
essential to guiding project consensus.
 Determining all the bits that go into the project scope
comes later in the project.
 During the initiation processes, the goal is to get the
majority of the stakeholders on the same page.
 To reach project consensus, your goal is to find common
ground, and then to address ancillary requests that don’t
infringe, change, or drive out the original project purpose.
REACHING PROJECT CONSENSUS

There are several approaches to accomplishing this goal:

 Conduct interviews
 Do root cause analysis
 Do business analysis
 Walk a mile in the stakeholders’ shoes
 DEALING WITH POLITICS

Follow these do’s and don’ts:

 Don’t feed the fire.
 If you can’t say something nice, don’t say anything at
all.
 Do stand up.
 Do protect your reputation.
 Don’t micromanage.
 Do play fair.
 THROUGH STATES

All projects are about changing some state through

a series of processes.
 INITIATING THE PROJECT
Projects get initiated to fulfill many different needs:
 A problem needs to be solved.
 An opportunity needs to be captured.
 A profit needs to be made.
 An existing environment needs to be improved.
 A process needs to be speeded up and/or made more
efficient.
 At the initiation stage, the PM must make an effort to
understand the reasons the project is necessary.
 INITIATING THE PROJECT
After identification of the need that the software project
is engineered to answer, we need to deal with some
mechanics of project management:
Conducting a feasibility study:
Determining the project deliverable:
Creating the project charter:
CONDUCTING A FEASIBILITY STUDY
 In formal project management a feasibility study
examines the high-level goals of the project, the
needed resources, and any other factors that could
influence the project’s success.
 The point of a feasibility study is to determine whether
this project can feasibly accomplish the time, cost, and
scope objectives.
 Sometimes the project isn’t feasible and the idea is
tanked, outsourced, sent back to the drawing board, or
even broken down into multiple projects.
DETERMINING THE PROJECT DELIVERABLE
 If the project is deemed feasible, then a product
description is created.
 The product description is an early rendition of the product
scope.
 The product scope for most software projects consists of
the design documents that detail the end result of the
software project.
 In some instances, the product scope is very detailed —
down to the color scheme, button fonts, and graphics. In
other instances, the customer leaves the details to the
project team, choosing instead to focus the product
description on detailing the ideal functions of the software.
CREATING THE PROJECT CHARTER
 A project charter is written by the person who has the
authority within an organization to authorize the project to
move forward.
 This individual has the positional power to authorize
resources and funds.
 The project charter may be written by the project manager,
but is signed by someone with more power in the
organization. This person typically becomes the project
sponsor.
 After the charter is signed by project sponsor, all key
stakeholders need a copy of the charter telling the about
the authority of PM and about Project Sponsor.
THE PROJECT CHARTER
A project charter accomplishes the following:
 It identifies the project manager in writing.
 It identifies the project sponsor in writing.
 It authorizes the project manager to spend organizational
resources on the project.
 It describes the product.
 It specifically identifies the business need that the project
was undertaken to address.
 A charter can’t solve all power struggles, negotiations, and
other miseries — it’s not a panacea. But a charter does,
more than anything else, authorize the project.
 PLANNING THE PROJECT
 The second process group, the planning process,
determines how the project will move forward after the
project feasibility, description, and charter are complete.
 Planning is an iterative (or repeated) process that happens
as many times as it must throughout the project life cycle.
 You instinctively plan and restructure your plan all the
time, stepping back, examining the problem, and then
creating and refining the solution.
 The point of planning in software project management is to
communicate exactly what you’ll be doing in the project.
It’s a guide for all future project decisions.
EXAMINING PROJECT PLANNING APPROACHES

Planning can be done in lots of ways. It can be very informal

way or one formal project management planning
methodologies.
 Rolling wave planning
 Scrum
 Extreme programming
PROJECT PLANNING APPROACHES
 Rolling wave planning: The concept of the rolling wave
approach is to crest with planning and then go do the work. You
have several successions of planning and executing your plan.
This is a fine approach in a software project.

 Scrum: Scrum calls for quick, daily meetings with members of the
project team. The focus of these meetings is simple i.e. to identify
what each team member has done so far, what team members
will be doing today, and what issues need to be solved in the next
week or so.

 Extreme programming: This software creation approach calls

for rounds of planning, testing, team involvement, and execution.
Communication and teamwork are paramount in this approach,
which puts a primary focus on customer satisfaction.
 EXECUTING THE PROJECT
 Execution, the third process group, is all about getting things
done. You authorize the project work to begin and your
project team goes about the business of designing, building,
and testing the project’s creation.
In this process group, you’re also tackling some other key
activities:
 Beginning your procurement activities, if needed
 Working with your organization’s quality assurance programs
 Communicating project information to appropriate
stakeholders
 Managing project risk assessments
 Developing the project team
 Managing conflicts among the team and among stakeholders
 CONTROLLING THE PROJECT
 The executing process group’s twin process is
controlling, which is the fourth process group.
 Controlling is all about ensuring the project is done
according to plan.
 PM controls — quality, scope, budgets, the schedule,
risks — and monitor performance.
 The Controlling and Executing depend on each other.
 CLOSING THE PROJECT
 The fifth process group, closing, for good project managers,
involves lots of activities, including the following:
 Tying up loose financial ends: Doing your final math to see where
the project stands financially, verifying the procurement documents,
verifying the deliverables, and so on.

 Unveiling the product to the customer for final acceptance:

When the customer is happy, he or she signs off on the project.

 Finalizing the project documentation: Final reports on the project

team, including time spent on the project, final costs, and so on, need
to be completed, as well as the lessons learned documentation.

 Moving on: The project manager and the project team go on to other
projects.
 PROJECT FEASIBILITY STUDY
 A project feasibility study (often just called a feasibility
study) determines whether a project is feasible with the
constraints tied to the project.
 For example, you might ask, “Can you create the desired
software in four months, with two developers, and a
proposed budget of $58,000?”
 A feasibility study looks at constraints, including the exact
details of the product scope, and allows you to explore
each of the issues and make a judgment.
 At the very least, a feasibility study enables you to present
the facts to managers so that they can determine what’s
feasible.
 WHAT FEASIBILITY STUDIES DO
Some reasons to consider conducting a feasibility study are
that these studies
 Can save time and money. Feasibility studies just make good
financial sense.
 Can give you and the stakeholders an opportunity to do a
risk assessment. Risks will be assessed in more detail when
planning the project, but an initial risk assessment at this
stage can help the organization determine whether a
marginal project should move forward.
 WHAT FEASIBILITY STUDIES DON’T DO
A feasibility study does not
 Serve as a research paper. It’s a factual exploration of the project’s
likelihood for success.
 Cheerlead the project manager’s point of view. For that matter, it’s
neutral all the way around and shouldn’t promote anyone’s point of
view.
 Present alternate ideas. Your focus is on the merits and pitfalls of the
project as it’s been articulated at this point. You shouldn’t be tweaking
the ideas.
 Campaign for additional time or funds. You must consider the lack of
time and money a risk and document the problem in a risk statement.
 Offer advice on the project’s initiation. A feasibility study just presents
the facts; it doesn’t make a recommendation for the project to be
launched or squelched.
 PROJECT SELECTION
Projects may get selected in one of two ways:
 Constrained optimization: This is a complex approach that
considers multiple variables, factors, and likelihood of
project success. Selection committees use dynamic
algorithms and linear and nonlinear programming to choose
their projects.
 Benefit comparison methods: Most organizations use this
approach. Benefit comparison methods use accessible
formulas, comparison models, and systems to choose which
projects should be launched and which should not.
 BENEFIT COMPARISON SELECTION MODEL

Managers compare projects and choose the best one for

your organization.
 A SCORING MODEL: A scoring model establishes a foundation
of desired attributes such as profitability, cost, timeline, return on
investment (ROI), required staffing, and so on. Each attribute is
assigned a value. As each proposed project is reviewed, the
attributes of the project are assigned scores. The projects with
the highest scores are chosen for launch.
 A MURDER BOARD: A murder board is a committee of
people who play the devil’s advocate against the project.
Their job is to ask all sorts of questions to look for the
project’s weaknesses.
 BENEFIT COMPARISON SELECTION MODEL

 A PROJECT’S ROI: The ROI concept is straightforward. If

you invest $100,000 in a project, a good ROI is one that
earns substantially more than $100,000.
 NPV
 IRR
 THE PRODUCT DESCRIPTION
One of the key activities for the project manager, the key
project stakeholders, the customers, and in some
instances, the project team is writing the product
description.
 The product description captures the essence of what
the project will create.
 It describes the deliverables, the function of the
deliverables, and how the product will affect the
organization.
 The product description is also known as the product
scope.
 THE PRODUCT SCOPE
Every product scope should include the following:
 Overall function of the software
 Features of the software the project will create or revise
 Purpose of the project work (whether it’s to solve a specific
problem, seize a particular opportunity, or what have you)
 Any optional or desired components that may be
incorporated into the product based on the project
manager’s discretion
 Metrics for product acceptance (speed, reliability, and
consistency, etc.)
THE PURPOSE, SCOPE & DELIVERABLE
 THE IDEAL TOOLS
Tools are the things you need to get the project work
done.
Following can be one of the list:
 Development language
 Hardware
 Training
 Other resources
 BUILDING A DREAM TEAM
A dream team is based on a combination of people skills
and technical competence. every team goes through four
phases of development:
• Forming: In this stage, folks all come together, shake hands, and
play nice.
• Storming: In this stage, attitudes, personalities, and alliances
begin to form.
• Norming: After roles have been clearly identified, politics have
been accepted or bucked, and things have calmed, you can focus
on how to get the work done.
• Performing: The project team has settled and is focused on
getting the work done.