SOFTWARE PROJECT MANAGEMENT (BIT 362)

Dr. Kate Takyi | KNUST

OVERVIEW
 Starting the Software Project
 Planning the Software Project
 Executing the Software Project Plan
 Controlling the Software Project
 Closing the Software Project
STARTING THE SOFTWARE PROJECT
Learning Objectives
 Examining the big picture of Project Management
 Initiating a software project
 Creating the software scope
Defining Software Projects
What is a Project?
 A project, technically, is a temporary endeavor to create a unique product or service.
 For some people, everything is a project; for others, projects are special, lofty activities
that occur infrequently.
 A project is a unique entity. In other words, the creation of a new application is unique,
whereas the maintenance and day-to-day support of an existing application is not so
unique.
 Projects can have many attributes:
Contd.
 They change or improve environments in organizations.
 They get things done.
 They are unique from other work.
 They have a defined start and end date.
 They require resources and time.
 They solve problems.
 They seize opportunities.
 They are sometimes challenging.
Defining Software Project Management
Project Management Definition
 Effective project management centers on the serious business of getting work done on time and
within budget while meeting customer expectations.
 Effective project management is about accomplishment, leadership, and owning the project
scope.
 It is an incredible feeling to sign off on the project and know that you and your project team
contributed to the project’s success.
 Management is concerned with one thing: results.
 Project management involves coordinating people, vendors, and resources.
 Project management requires excellent communication skills, a strong will to protect the project
scope, and leadership skills to enforce quality throughout the project work.
Comparing Projects to Operations
 There is a distinct difference between projects and operations. Operations are the day-to-day
activities that your organization does.
 For example, a car manufacturer makes cars. An airline flies people from one city to another. A
help desk supports technical solutions. Within each of these companies reside various
departments working on projects that enable operations to function.
 A project at an automobile manufacturer might be to design a new sports car. The car
manufacturer’s operations involve manufacturing that design again and again.
 Each project has its own requirements, its own purpose, its own budget, and its own project
manager and project team. Each project has its own resources, schedule, budgets, and goals.
 Some companies have changed their approach to business by treating all of their operations as
projects.
 This microscale of their enterprise, where every activity is part of a project and all projects
contribute to the betterment of the organization, is called management by projects.
Examining Project Constraints
 A constraint is anything that restricts the project manager’s options. Constraints are
requirements, confines, or, if you’re a glass-is-half-empty kind of person, prison walls.
Constraints can include
 Resource constraints such as a team member being assigned to too many concurrent
projects
 Tight deadlines
 Budgetary limitations
 Government regulations
 Limitations of software
 Scope limitation, such as being required to use a particular existing interface
 Hardware requirements
 Anything else that restricts your options
Understanding Universal Constraints
(Time, Cost, and Scope)
The three universal project constraints you will always face are
 Time: Time constraints may range from a reasonable schedule to an impossibly short time
frame that can’t budge because the product simply must be on shelves by a specific date
( eg. September 15)
 Cost: Cost constraints are the usual budgetary restrictions that you expect. (“Here’s a GHS
2,000. Make it happen.”)
 Scope: Sometimes scope is a no-brainer (you’re working on a software to fix a bug). On
the other hand, scope can be a bit trickier if you’re dealing with an executive who isn’t sure
what he wants.
 These three constraints make up what we refer to as the Iron Triangle of project
management.
 Check out Figure 1-1. Each side of the Iron Triangle represents one of the triple constraints.
For a project to be successful, each side must remain in balance with the other two.
 For example, say your boss decides to add more stuff to the project scope (now
instead of simply fixing a mathematical bug in your accounting software, you have to
create a whole new feature in the software that edits photos and home movies).
 Even though your boss has changed the scope, you have to deliver more stuff within
the same amount of time and with the same amount of cash, as Figure 1-2 depicts.
You’ll need more time, more money, or both for the triangle to remain equilateral.
Managing time constraints
 Time constraints are simply deadlines. You have a project to create a new piece of
software within six months. Or there’s an opportunity in the marketplace for a new
application, but the window of opportunity is small, so you have no time to waste.
 Time can also be calculated as labor: Working or billable hours, processor speed,
database consistency, and even network latency issues can be used to estimate time
constraints.
 Time constraints require more than just hitting a target deadline: Unavailable
resources (your ace programmer is on vacation), skewed milestone targets within the
project, conflicting versioning deadlines, and so on, all present constraints on the
project’s timeline.
 In summary, a time constraint is any factor or issue that changes or impacts the
original timeframe of the project. (No time machines allowed in project management,
sorry.)
Managing cost contraints
 Cost constraints are easy to identify because they mostly deal with cash money. For
example, the miniscule funds in your project budget to complete the project work
create a unique constraint.
 Your costs include computers and languages to code in, labor, and anything else you
need to buy in order to get the job done.
 Projects almost always cost somebody something. Be sure to factor in hidden costs for
labor, resources, computers, pizza, celebrations, training, and more.
Managing the scope
 There are two scopes within project management:
 Product scope: The product scope describes, lists, and categorizes all the features
and components of the finished deliverable.
 This is what the customers see in their minds’ eye.
 Project scope: This is where you focus. The project scope is all the required work, and
only the required work, to create the project deliverable.
 The project scope focuses on work, activities, and progress to achieve the product
scope. The project scope must be protected from unapproved changes because it
dictates what the project team will do and what the end result of the project will be.
 The product scope and the project scope work hand in hand. The product scope gives
details in the project scope and the project scope returns the favor by giving us what is
expected at the end.
 Each scope depends on the other, and what happens in either scope affects the other.
If there is disharmony between these two scopes, trouble is brewing.
 In the Iron Triangle the project manager’s concern is on the project scope — the project
work.
 The project manager must direct the project team to do the required work, nothing
more or less, to deliver exactly what the product scope calls for.
 This is not saying the project manager should hold back good designs, ideas, and
incredible features that the customer may want and can use.
 However neither the project manager nor any stakeholder, can arbitrarily add features
to the software because doing so would be to change the project scope.
Controlling the Scope Creep
 Changes to the project scope can affect cost and time constraints, melting your Iron
Triangle.
 The Iron Triangle is a key tool in project management and is ideal for negotiations with
stakeholders.
 For example, if your stakeholder insists on adding software functionality to your project
scope, you can use the Iron Triangle as a tool to explain that when you increase one side
of the triangle (the scope side) the triangle is no longer in balance.
 To change the scope, you must change the cost or the schedule (or both) to keep the
triangle balanced.
 The Iron Triangle is also a terrific tool to use in discussions with the project team, and to
keep your own duties as project manager in alignment.
 Unplanned changes to the project scope, sometimes called scope creep, are the little
extras that expand the scope without reflecting the changes in the cost and time
baselines.
 The reason scope creep is so poisonous is because it can happen so easily, and so innocently. And
yet, it can be so deadly.
 When the scope goes off track, time and funds are stolen from the original baselines.
 Balancing the three sides of the triangle ensures a high-quality final product. Changes to the
project scope should be controlled and managed through a change control system,
 In essence, a change control system accommodates a process for documenting requested changes
and requires obtaining appropriate approval for all requested project changes.
Making Sense of Project Success (Or Failure)
 Most projects start with an optimistic attitude about creating a deliverable, keeping the
customer happy, and making this the best software project ever. And then things (bad
things) happen.
 The good projects end on time and as planned. These projects have three things in
common:
 A leader who knows what he or she is doing
 A tight change control system
 Team members who understand what the project is supposed to deliver and can therefore get
results

 Commonly, projects limp to the finish line, late, overbudget, and after crushing the
morale of everyone involved. Done, but maybe not done well. These projects typically
have three attributes:
 Poor requirements from the project customers
 Poor communications through the project manager
 Poor morale from the project team
 The saddest of projects are the ones that never make it to the finish.
 This bunch misses deadlines, blows budgets, or experiences a radical change of scope so often
that no one (not even the PM) knows exactly what the project should be creating anymore
 Failed projects usually have some, if not all, of these attributes:
 No clear vision of what the project priorities are
 Lack of leadership from the project manager and/or sponsor
 A timid project manager
 Lack of autonomy for the project manager
Starting and Finishing Software Projects
 All projects pass through five process groups as defined by the Project Management
Institute.
 A process group is a mini life cycle that moves the project one step closer to
completion.
 Process groups are cycles because the processes don’t just happen once; they are
repeated throughout the project as many times as needed.
 The processes flow organically, in the order that best suits the needs of the project. It
is not recommended to keep repeating some of these stages. However if your project
isn’t going according to plan you will have to do just that.
 All projects, software and otherwise, go through these project management
processes. Each of these project management processes has its nuances.
 Initiating: That’s really where you are now. The project is in the process of getting
selected, sponsored, funded, and launched.
 Planning: As you can see in Figure 1-4, planning is an iterative process. Planning
basically determines how the project work will get accomplished.
 Executing: After you get a plan, your project team does the work.
 Controlling: Your project team does the work, but you control them.
 Closing: After the project work has been completed, you tie up loose ends and close
out the software project.
Understanding What Makes Software
Project Management So Special
 There’s nothing special about software project management that changes the Iron
Triangle or the five process groups.
 What is special about project management, however, is the nature of the work.
 Just as the particulars of designing a new warehouse, building a house, or creating a
prototype for a remote controlled airplane are unique, so is the creation of software:
 Software development is weird and requires a specialized skill set to do it well.
 Software creation is tough.
 Software development can be boring, routine, and mind numbing.
 Software creation can create challenges within the development of the code.
Breaking Moore’s Law
 in 1965, Gordon Moore wrote a scientific paper called “Cramming More Components
onto Integrated Circuits.”
 The synopsis of his paper is that the number of transistors per integrated circuit could
double every two years.
 The theory became known as Moore’s Law.
 The importance of Moore’s Law in software project management is that more
transistors per circuit mean faster processors. Faster processors mean more elaborate
software. More elaborate software means we need faster processors.
 Because information technology (IT) drives many businesses today, there is a direct
connection between the speed of technology and an organization’s bottom line.
 Between the two is the software the organization relies on. Consequently, businesses
demand software that’s reliable, secure, and scalable.
Dealing with Moore
 As your project moves towards completion, chances are there will be leapfrogs in the
technology you’re dealing with.
 There’ll be new versions of operating systems, service packs to address problems in
versions of software your software relies on, and more.
 Part of software project management is to have a plan to address these potential
changes.
 Every (yes, every) software project manager should have an allotment of time added
to the project schedule specifically for planning and responding to Moore’s Law.
 What if you are not given enough time? What do you do?
 By relying on historical information, you can help your project adjust to Moore’s Law.
 If you have documented instances of past projects that failed because of a lack of time
to respond to changing technology, use it.
 If you have records of your past projects, you can show how the project would have, or
at least could have, been more successful with this allotment of time.
 This is a good time to remind you to save your project documentation so that you and
other software project managers can use it for the same purpose in the future.
 If you don’t have these project records, well, there’s good news and bad news. The bad
news is that it’s hard to argue for additional time for planning without proof of why the
time will be needed.
 The good news is that you can start now. Without the additional time allowed for your
project, here’s what we recommend:
 Do a thorough risk assessment. Document how the risks due to changes in
technology could contribute to failure.
 Document lost time. Document any lost time tied to technical changes (research,
team training, subject matter experts, and so on).
 Document lessons learned. Begin your lessons learned documentation, a document
that highlights all the lessons learned, with attention to technology changes, at the
start of the project, and as your software project progresses, complete your lessons
learned documentation.
 Communicate proactively. Communicate to your stakeholders when changes to
technology enter and influence your project.
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 and its goals. If not, you can count on trouble before the project
is complete.
 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
 When a project is being initiated, you want to capture as much information as possible
about the project goals to get a clear picture
 Stakeholders, from your customers to senior management, will have different
concepts about what signifies that a project is complete. Here are five questions every
project manager should ask stakeholders:
 What are the factors for completion? You should ask this key question far in advance
of starting the project work.
 As a project manager you need to know what the project will accomplish and be able to plan
how to get there.
 Starting a project without knowing what the end result should be is like building a house
without blueprints.
 What is the goal of this project? Knowing the project’s goal helps you and the team
plan.
 For some projects the goal will be to win new customers, or to make internal processes more
efficient, or to solve a problem.

 What are the areas of the organization that this project will affect? The answer to
this question tells you who you need to communicate with.
 It also brings to attention that there may be stakeholders who aren’t attending meetings and
should be.

 What is the project priority? Chances are good you’ll be managing more than one
project at a time, and there are equal chances that your project team members will be
on multiple projects as well.
 When you consider these odds it’s best to know your priorities so you know where to spend
your energy.

 What is the accepted range of variance? The range of variance is the +/– value
associated with the budget and the schedule.
Reaching project consensus
 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.
 There are several approaches to accomplishing this goal:
 Conduct interviews: This is fundamental business. You and the key stakeholders must
meet several times before the project work begins so that you can discuss the project
goals and determine whether both parties are in agreement to the project
deliverables.
 Do root cause analysis: If your project is to create software that solves the problem of
multiple databases and recursion issues, a root cause analysis can help you design a
solution by examining potential causes to specific problems.
 Do business analysis: Some organizations use a business analyst to serve as the
liaison between the project manager and the key stakeholders.
 A business analyst can lighten the burden of the project manager by gathering and
prioritizing the project needs for the project manager and the key stakeholders.
 Walk a mile in the stakeholders’ shoes: Sometimes the easiest approach to reaching
consensus is to experience the pain the project customer is experiencing. If the
stakeholders need an application to take orders via the Web, experience how they take
orders now.
 If the stakeholders hate their current toolbars, macros, or forms, monkey around with
the current software interface.
 If you can see things from their perspective, it’ll help you solve the problems faster.
Initiating the project
 The first process group is initiation. When a project is initiated, it is being considered; it
hasn’t been officially launched. Projects get initiated to fulfill many different needs,
some of which we’re sure you’ve experienced, and most of which can be addressed
with software:
 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. Knowing why the project is being created will help you ask the
right questions to help the customer get to the desired solution.
 After you identify the need that the software project is engineered to answer, you
need to deal with some mechanics of project management:
 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 than you.
 This person typically becomes the project sponsor.
 Technically, the charter should be signed by a person whose role in the organization is higher
than all managers that may have employees on your project team.
 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. That’s right; the description you worked so hard to create
goes in the project charter.
 It specifically identifies the business need that the project was undertaken to address.
If you have a business case, you can pull information from there.
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.
 The planning process group gets the project rolling in a big way.
 Planning isn’t a one-time deal. 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 a lots of ways. You and your team can sketch out a plan on the
back of a napkin to create a formal detailed approach to delivery.
 Or you can follow one of these formal project management planning methodologies:
 Rolling wave planning: Waves crest before they fall. 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. You 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.
 This is the meat of the project — doing the work.
 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. You control stuff —
quality, scope, budgets, the schedule, risks — and you get to monitor performance.
 Don’t forget to document all these changes in performance so that you can write up a
thorough lessons learned document later.
 The reason we relate controlling and executing is that they (more than all the other process
groups) depend on each other.
 As your project team executes the project plan, you control the work by ensuring the
quality is present as planned.
 You ensure that the costs are kept in check, and that the schedule is consistent, as planned.
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.
 Finally, you can archive the project records, and if you’ve been working on gathering
historical documentation all along, this part should go surprisingly smoothly
 Moving on: And then the project manager and the project team go on to other
projects. Well, not yet. Don’t forget to celebrate with your project team for a job well
done!
 If the project is a success, it’s because of everyone’s great effort; if the project fails,
then it’s your fault, and your fault alone.
 That’s just the way project management goes. It’s not always fun, not always
rewarding, and it’s never easy.
Writing 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.
 You have to write the product description during the initiation stage because it
officially captures what the project will create.
 Verbally everyone can agree on what the project will create, but to have it on paper
makes it official.
 The product description is also known as 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, for example)
Process to Project Completion
Finding the ideal tools
 Tools are the things you need to get the project work done. They can include anything from
hardware (two monitors, faster processors) to the language you’ll be using to develop the
software.
 Development language: You need to know which code will deliver the product the fastest,
and which code will deliver the best product for the customer.
 Hardware: Most of the hardware is difficult to come by nowadays. Ensure every hardware
required comes on board.
 Training: If some or all members of the project team don’t know how to do the work, train
them or send them to training. This is part of team development, the cost of quality, and it
has huge effects on team morale.
 Other resources: Typically, when people think of resources they think of people, but
resources are also things. And the things you want on your wish list are items that
keep your developers happy. So the resources you want here can range from sodas
and pizzas to reference books and Internet subscriptions to relevant IT Web sites.
END OF PRESENTATION