Project Management Concepts

by Ronni Kahalani, Copenhagen School of Design & Technology.

With inspiration from the book Software Engineering - A Practitioner's Approach.

​

Project management involves the planning, monitoring,

and control of people, process, and events,

from a preliminary concept to full operational deployment.

Who am I?

Thank you for stopping by.

​

I’m Ronni. I hope you’re well and wish you a safe and worthy journey.

​

This presentation is part of the Software Engineering Series, from my lectures at Copenhagen School of Design & Technology.

​

You can view the Introducing Myself, if you want to know a little more about who I am.

​

All my presentations and materials are free and available at my blog post: Software Engineering.

​

​

Don’t let me uphold you,

continue your journey, go to next slide.

2

X /Twitter

@RonniKahalani

�LinkedIn

https://www.linkedin.com/in/kahalani/

�Blog�LearningIsLiving

Agenda

• Intro
• Quick Look
• The Management Spectrum
• The People
• The Product
• The Process
• The Project
• People
• The Stakeholders
• Team Leaders
• The Software Team
• Agile Teams
• Coordination and Communication Issues

• The Product
• Software Scope
• Problem Decomposition
• The Process
• Melding the Product and the Process
• Process Decomposition
• The Project
• The W5hh Principle
• Critical Practices
• Summary

Intro

Management techniques required to plan, organize, monitor, and control software projects.

• How must people, process, and problem be managed?
• How can software metrics be used to manage?
• Generate reliable estimates of effort, cost, and project duration
• Assess the risks that can have an impact
• Select the set of software engineering work tasks
• How is a project schedule created?
• Why are maintenance and reengineering so important?

Intro

“I've visited dozens of commercial shops, both good and bad, and I've observed scores of IT managers, again, both good and bad. 

Too often, I've watched in horror as these managers futilely struggled through nightmarish projects, Squirmed under impossible deadlines, or delivered systems that outraged their users and went on to devour huge chunks of maintenance time. “

 - by Meiler Page-Jones

​

If a postmortem were to be conducted for every project, it is very likely that a consistent theme would be encountered:

Project management was weak.

Quick Look

• What is it?
• Project management involves the planning, monitoring, and control of the people, process, and events from a preliminary concept to full operational deployment.
• Who does it? - Everyone "manages" to some extent
• Software engineer manages day -to-day activities, planning, monitoring, and controlling technical tasks
• Project managers plan, monitor, and control the work of a team of software engineers
• Senior managers coordinate the interlace between the business and software professionals
• Why is it important?
• Building computer software is a complex undertaking
• Particularly if it involves many people working over a relatively long time

Quick Look

• What are the steps?
• Understand the 4P’s
• What is the work product?
• A project plan. The plan defines the process and tasks to be conducted, the people who will do the work, and the mechanisms for assessing risks, controlling change, and evaluating quality
• How do I ensure that I've done it right?
• You're never completely sure until you've delivered a high-quality product on time and within budget
• When he encourages people to work together as an effective team, focusing their attention on customer needs and product quality

The Management Spectrum

Effective software project management focuses on the 4Ps.

The Management Spectrum

Effective software project management focuses on the 4Ps:

• People
• Software engineering work is an intensely human endeavour
• Product
• Not encourage comprehensive communication early in the evolution of a product risks building an elegant solution for the wrong problem
• Process
• Little attention to the process runs the risk of inserting competent technical methods and tools into a vacuum
• Project
• Without a solid project plan jeopardizes the success of the project

​

The People

“People factor" is so important that the Software Engineering Institute has developed a People-CMM (People Capability Maturity Model).

​

“Every organization needs to continually improve its ability to attract, develop, motivate, organize, and retain the workforce needed to accomplish its strategic business objectives“

​

People-CMM is a companion to the Software Capability Maturity Model-Integration. (ed.8 - ch.37 / ed.9 - ch.28) that guides organizations in the creation of a mature software process.

The People

Defines the following key practice areas for software people:

• Staffing
• Communication and coordination
• Work environment
• Performance management
• Training
• Compensation
• Competency analysis and development
• Career development
• Workgroup development
• Team/culture development
• …and others…

The Product

Before a project can be planned:

• Product objectives and scope should be established
• Alternative solutions should be considered
• Technical and management constraints should be identified

​

Why?

• It is impossible to define reasonable cost & risk
• Realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress

​

The Product

In many cases, 1st step in software requirements engineering.

You and other stakeholders must meet to define product objectives and scope.

• Objectives identify the overall goals for the product without considering how these goals will be achieved
• Scope identifies the primary data, functions, and behaviours to bound these characteristics in a quantitative manner
• Alternative solutions are considered, 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 Process

A small number of framework activities are applicable to all software projects, regardless of their size or complexity.

​

Adapted to the characteristics of the software project and the requirements of the project team:

• Tasks, milestones, work products and quality assurance points

​

Umbrella activities-such as software quality assurance, software configuration management, and measurement�- overlay the process model.

The Project

Conduct planned and controlled software projects for one primary reason…Why?

- It is the only known way to manage complexity!

​

And yet, software teams still struggle ☹

- Study 250 large software projects between 1998 – 2004, � (ed.8 – p.686 / ed.9 – p.492)

​

• Avoid a set of common warning signs, understand the critical success factors that lead to good project management
• Develop a common sense approach for planning, monitoring, and controlling the project

People

Managers argue that people are primary, but their actions sometimes belie their words.

The Stakeholders

The software process/project is populated by stakeholders who can be categorized into 1 of 5 constituencies:

1. Senior managers
2. Project/technical managers
3. Practitioners
4. Customers
5. End users

Project team must be organized in a way that maximizes each person's skills and abilities.

- And that's the job of the team leader.

Team Leaders

Jerry Weinberg suggests an MOI model of leadership:

• Motivation
• Organization
• Ideas or innovation

​

Another view of the characteristics that define an effective project manager emphasizes 4 key traits:

• Problem solving
• Managerial identity
• Achievement
• Influence and team building

The Software Team

There are almost as many human organizational structures for software development as there are organizations that develop software.

​

“Best“ team structure depends on:

• Management style of your organization
• Number of people who will populate the team and their skill levels
• Overall problem difficulty

The Software Team

Mantei describes 7 project factors that should be considered when planning the structure of software engineering teams:

1. Difficulty of the problem to be solved
2. “Size" of the resultant program(s) in lines of code or function points
3. Time that the team will stay together (team lifetime)
4. Degree to which the problem can be modularized
5. Quality and reliability of the system to be built
6. Rigidity of the delivery date
7. Degree of sociability (communication) required for the project

The Software Team

Constantine suggests 4 "organizational paradigms“ for software engineering teams:

1. Closed paradigm
• Traditional hierarchy of authority
2. Random paradigm
• Loosely and depends on individual initiative of the team members
3. Open paradigm
• Achieves some controls but also much of the innovation
4. Synchronous paradigm
• Relies on the natural compartmentalization of a problem

The Software Team

“Jelled team” - by DeMarco and Lister from the book “Peopleware”

​

What’s that? (ed.9 – p.494)

• Synergy - Unstoppable - A juggernaut for success
• Don't need to be managed in the traditional way
• Don't need to be motivated

​

They share a common goal, a common culture, and in many cases, a "sense of eliteness" that makes them unique.

​

​

​

They've got momentum!

The Software Team

Not all teams jell, many teams suffer from "team toxicity.“� – by Jackman

​

She defines 5 factors that "foster a potentially toxic team environment“:

1. A frenzied work atmosphere
2. High frustration that causes friction among team members
3. A "fragmented or poorly coordinated" software process
4. An unclear definition of roles on the software team
5. Continuous and repeated exposure to failure

The Software Team

In addition to the 5 toxins…

• Some team members are extroverts vs. others are introverts

​

• Some people gather information intuitively, distilling broad concepts from disparate facts vs. Others process information linearly, collecting and organizing minute details from the data provided

​

• Some team members are comfortable making decisions only when a logical, orderly argument is presented vs. Others are intuitive, willing to make a decision based on "feel“

​

​

The Software Team

In addition to the 5 toxins…

• Some practitioners want a detailed schedule populated by organized tasks that enable them to achieve closure for some element of a project vs. Others prefer a more spontaneous environment in which open issues are okay

​

• Some work hard to get things done long before a milestone date, thereby avoiding stress as the date approaches vs. Others are energized by the rush to make a last-minute deadline

​

It is important to note that recognition of human differences is�the first step toward creating teams that jell. 

Agile Teams

To review, the agile philosophy encourages:

• Customer satisfaction and early incremental delivery of software
• Small highly motivated project teams
• Informal methods
• Minimal software engineering work products
• Overall development simplicity

​

However, the agile philosophy stresses individual competency coupled with group collaboration as critical success factors for the team.

Agile Teams

 - by Cockburn and Highsmith:

• If the people on the project are good enough, they can use almost any process and accomplish their assignment.�If they are not good enough, no process will repair their inadequacy� - “People trump process” is one way to say this.
• However, lack of user and executive support can kill a project – “politics trump people”
• Inadequate support can keep even good people from accomplishing the job ...

Agile Teams

Agile teams are self-organizing.

• Does not necessarily maintain a single team structure
• Uses elements of Constantine's random, open, and synchronous paradigms

​

An agile team might conduct daily team meetings to coordinate and synchronize the work that must be accomplished for that day.

• The team adapts its approach in a way that accomplishes an increment of work

​

Coordination and Communication Issues

There are many reasons that software projects get into trouble

- facts of life…

Deal with them effectively, establish effective methods for coordinating:

• Formal communication: Writing, structured meetings, and other relatively non-interactive and impersonal communication channels
• Informal communication(more personal): Members of a software team share ideas on an ad hoc basis, ask for help as problems arise, and interact with one another daily

See “Safe Home” (ed.8 – p.693 / ed.9 – p.496)

The Product

The dilemma at the very beginning of a software project.

​

​

The Product

A software project manager is confronted with a dilemma at the very beginning of a software project.

• Quantitative estimates and an organized plan are required, but solid information is unavailable
• A detailed analysis of software requirements would provide information necessary for estimates

​

At a minimum, the scope of the product�must be established and bounded.

Software Scope

The first software project management activity is the determination of software scope.

​

Answer following questions:

• Context
• Information objectives
• Function and performance

​

Must be:

• Unambiguous and understandable at the management and technical levels
• Bounded
• Quantitative data
• Stated explicitly
• Mitigating factors

Problem Decomposition

Sometimes called partitioning or problem elaboration.

During the scoping activity no attempt is made to fully decompose the problem.

​

• Applied in 2 major areas:
1. Functionality and content (information) that must be delivered
2. 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 problem.

The strategy that applies as project planning begins.

The Process

The team decides which process model to use.

The Process

The team decides which process model is most appropriate for:

1. The customers who have requested the product and the people who will do the work
2. The characteristics of the product itself
3. The project environment in which the software team works

​

The team defines a preliminary project plan based on the set of process framework activities.

​

Once the preliminary plan is established, process decomposition begins.

• A complete plan, reflecting the work tasks required to populate the framework activities.

Melding the Product and the Process

Assume that the organization has adopted the generic framework activities:

• Communication
• Planning
• Modelling
• Construction
• Deployment

The team members who work on a product function will apply each of the framework activities to it. 

A matrix is created.

Melding the Product and the Process

Each major product function (word -processing software) is listed in the left-hand column.

​

Framework activities are listed in the top row

Melding the Product and the Process

• Software engineering work tasks would be entered in the following row. (for each framework activity)
• The job of the project manager (and other team members) for each matrix cell is to:
• Estimate resource requirements
• Define start- and end dates for the tasks associated
• Work products to be produced as a consequence of each task

The Project

Understand what can go wrong so that problems can be avoided.

The Project

Understand what can go wrong so that problems can be avoided

• Software people don't understand their customer's needs
• This leads to a project with a poorly defined scope.
• Changes are managed poorly
• Chosen technology changes or business needs shift and management sponsorship is lost
• Management can set unrealistic deadlines or end users can be resistant to the new system.
• Project team does not have the required skills
• Some developers never seem to learn from their mistakes

​

The Project

Jaded industry professionals often refer to the "90-90 rule“.

• The first 90 percent of a system absorbs 90% of the allotted effort and time.
• The last 10 percent takes another 90% of the allotted effort and time

​

​

But enough negativity!

How does a manager act to avoid the problems just noted? 

The Project

Reel suggests a 5-part common sense approach to software projects: 

1. Start on the right foot
2. Maintain momentum
3. Track progress
4. Make smart decisions
5. Conduct a post-mortem analysis

​

The W5hh Principle

Series of questions that lead to a definition of key project characteristics and the resultant project plan.

The W5hh Principle

Barry Boehm states: "You need an organizing principle that scales down to provide simple project plans for simple projects.“

Suggests an approach that addresses:

1. Project objectives
2. Milestones and schedules
3. Responsibilities
4. Management and technical approaches
5. Required resources

Applicable regardless of the size or complexity

The W5hh Principle

Series of questions that lead to a definition of key project characteristics and the resultant project plan:

• Why is the system being developed?
• What will be done?
• When will it be done?
• Who is responsible for a function?
• Where are they located organizationally?
• How will the job be done technically and managerially?
• How much of each resource is needed?

Applicable regardless of the size or complexity

Critical Practices

The Airlie Council has developed a list of�“critical software practices for performance-based management."

​

Critical practices include:

• Metric-based project management
• Empirical cost and schedule estimation
• Earned value tracking
• Defect tracking against quality targets
• People aware/oriented management

​

Each of these critical practices is addressed throughout Part 4.

Summary

Software project management is an umbrella activity within software engineering.

​

• It begins before any technical activity is initiated and continues throughout the modelling, construction , and deployment
• 4P’s have a substantial influence on software project management:
• People
• Product
• Process
• Project

Summary

The project management activity encompasses:

• Measurement and metrics
• Estimation and scheduling
• Risk analysis
• Tracking
• Control

​

The pivotal element in all software projects is people.

Questions?

Anything? What’s on your mind? Come on ask me anything…

​

Feedback?

Thank you for your precious time.

I hope it was worth it and would love to get your feedback.

​

Please share your feedback here