Software Project Management

INFO 638 Lecture #6 1

Software Project Management

Team management and project closeout

INFO 638Glenn Booker


Managing a Team

One of the key powers of management is to create organizational structures Doing so poorly can sabotage the best

personnel before the project starts But with good organization, even

ordinary people can produce good products


Project vs. Functional Managers

The Project Manager is responsible for the whole project’s successful completion

The Functional Manager (Wysocki’s term) is the person responsible for staffing the project, and matching people’s skills to the project’s requirements


Project vs. Functional Managers In common terms, the functional

manager (FM) might be a manager of people with a particular skill set, e.g. database analysts or interface designers

Whereas the project manager is responsible for using the people “owned” by the FM to get a given project done


Motivation

Motivation is a key ingredient to baking a good team (ouch, lousy analogy)

Just like the director of a play doesn’t control the actors once they take the stage, the PM and FM can only set up good conditions for a team to work well (ok, that’s better)

Another key contribution to a team’s success is their motivation


Motivation

Key for a good manager to recognize is that different things motivate different people And what motivates one person might

change over time One person might be thrilled to get an

award for their contribution to a project, another might prefer a check, and a third might want an extra two days vacation


Motivation

The big motivational factors for most people are: Opportunity for achievement Opportunity for advancement

Might include technical supervision Recognition Increased responsibility The work itself


Motivation

The environment in which you work is considered hygiene factors, which don’t contribute directly to motivation, but could detract from it

The hygiene factors are Company policies and practices, working

conditions, your management, interpersonal relations, job security, and salary


Motivation

An aside – many people would put salary as their first motivational factor

These factors are based on landmark 1959 study by Frederick Herzberg Maybe nobody needed money as much

back then?


Management and Motivation

Many of the motivational factors can’t be controlled by a first line manager

Key for managers to focus on are Provide challenging work Recognize your people’s work Design their job to provide a variety of

skills needed, clearly identifiable and significant tasks, allow autonomy, and provide feedback


Recruiting a Team

Creating a great team is a challenging form of alchemy

You need the right blend of skills to get the job done, and yet balance other characteristics (e.g. personality, salary demands, etc.) to get a viable collection of people


Recruiting a Team

Assuming you aren’t the PM, the key types of recruiting are for: The project manager Core team members (those drawn from

within your organization) Contract personnel (people hired just for

this project)


PM Recruiting

The project manager typically needs to be brought on board very early in the project Like, before it starts

Key selection criteria include Relevant background experience

Yes, Brownie, it does make a difference!


PM Recruiting Leadership and strategic expertise

The PM has to coordinate issues above the project level, so broader experience is important

Technical expertise Some believe a generic manager can

manage anything; in most technical fields, this isn’t true

Interpersonal experience Ability to plan, manage


Core Team Recruiting

The core team consists of the people who will also tend to be with the project from start to finish

They are typically identified when the project scope is defined

They need to be balanced in terms of skills, especially if voluntary turnover is a problem


Core Team Recruiting

Key characteristics include Commitment to the project Shared responsibility for project success Flexibility to do what’s needed Results-oriented Able to work with schedule & resource

constraints Trust and mutual support of the team


Core Team Recruiting Must play nicely with others (a team

player) Open minded to alternative problem

solutions Able to work with everyone Able to use project software tools


Contract Team Recruiting

Depending on the project, contract personnel may or may not be needed

Generally required when staffing and/or specific skills aren’t available in-house

Typically are called upon for a short period within the project



Key challenge is getting them up to speed quickly May need to monitor their work quality

Key characteristics include Skills needed Number of people When they are needed



Once staffing needs are identified, make a list of sources for personnel

Write and distribute a request for proposal (RFP), defining the needs

Evaluate the RFP responses Give best candidates a chance to

make a formal presentation Choose the source, and write contract


Contract Issues Many management issues involve

contractual concerns A good resource with more detail is

On Time Within Budget, E.M. Bennatan, 3rd ed., ISBN 0-471-37644-2, Wiley, 2000.

The key contractual vehicles are RFI, RFP, and RFQ For zillions of examples, go to

www.firstgov.gov and search on those acronyms


RFI – Request for Information An RFI is used to identify reasonably

well qualified vendors …and screen out unqualified ones

It outlines the general scope of an intended project or contract, and asks for potential vendors to prove they are qualified to work in that area

Qualified potential vendors then get an RFP or RFQ


RFP – Request for Proposal

An RFP defines specific project needs and requirements, and asks potential vendors to tell how they would solve the problem presented, and give specific commitments for the time and effort to do so


RFP – Request for Proposal

An RFP includes detailed criteria on how the vendors will be judged

A large RFP may have separate management, technical, and cost volumes


RFQ – Request for Quotation Or “Request for Quote” An RFQ is used to get a bid or

quotation on a well known, common type of product E.g. office supplies, computer

components, etc. The main distinguishing feature of

bids is simply price; delivery schedule may also play a role


Contracts

There are several types of contracts, depending on the complexity of the transaction Retainer Time & materials Time & materials – not to exceed Fixed bid Fixed price incentive fee


Retainer

A retainer contract pays a certain fixed amount per month

Up to some defined amount of work can be expected per month; beyond that some hourly rate is set

Typically use retainer for very specialized skills from outside your organization


Time & materials

Used for very vague scope contracts, a time & materials contract pays for the amount of effort expended on the contract Plus paying for material costs

The ‘not to exceed’ clause is to keep from getting billed way more than expected for a given set of tasks


Fixed bid

A fixed bid puts the risk on the vendor – a given set of tasks will be accomplished for a set price

If it takes more work than expected, the vendor eats the additional costs


Fixed price incentive fee

A fixed price incentive fee contract (not in the text) adds bonuses if the vendor exceeds requirements for the project (is faster than required, has more capacity, etc.)


Contract examples

Lawyers and people with rare skills (e.g. SAP experts) might be put on retainer

Research contracts and work on novel systems might use time & materials

Many software development contracts using established technologies use fixed bid or fixed price incentive fee


Contract Terms

The terms of payment are clearly defined in any contract Often payments are based on meeting

specific milestones in the project Rules for handling contract early

termination, and normal closeout of the contract are also defined


Team Organization

A key decision for a project manager is the delegation of authority How much is enough?

Too much and you lose control of the project

Too little and work can’t get done efficiently

Responsibility can’t be delegated The PM is responsible for the work of all

people under them


Team Balance People tend to follow four major

approaches when on a team Assimilate data & ideas quickly, focusing

on the theory more than the problem Diverge, and look at the problem from

many perspectives Accommodate people’s views and keep

conflict to a minimum Converge on a solution, focusing on the

technology more than people


Team Rules Any team needs some rules to

function effectively How will decisions be made? How do you solve problems? How do you resolve conflicts? How & when does the team meet? How does the team interact

with other projects? The customer? Who defines the answers to these?


Project Closeout


Closeout

Normal closeout of a project typically involves six steps Get client acceptance Ensure system installed Ensure documentation delivered Get client signoff Post-implementation Audit Party!


Get client acceptance

This can be formal or informal Formal acceptance involves following

your customer’s acceptance procedure May involve customer-run testing to prove

requirements have been met Informal acceptance either means you

are done within the stated time limit, or there is no formal acceptance needed


Ensure system installed

This step means you have installed the production system, and it has gone live (is in production; is operational; there are lots of terms)

This step is the conclusion of your project cutover, rollout or deployment strategy


Ensure documentation delivered

Everyone loves to forget documentation

This step reminds you to deliver all of the promised documentation May include requirements, design,

implementation, maintenance, training, and other documentation

May include documenting the total effort and schedule needed for completion


Get client signoff

Once the system is in place, and everything has been delivered, the customer can formally accept completion of the contract

This has legal ownership implications – the system now belongs to them

Might be done with much fanfare


A note on FCA/PCA

To formally accept a system, functional and physical configuration audits (FCA and PCA) may be done FCA is the act of proving that the system

requirements have been fulfilled PCA gives a detailed accounting of all

components, code, and documentation in the final system (as if to say, “here’s what you got for your money”)


Post-implementation Audit

A.k.a. a post-mortem for the project This audit is to assess how well the

project went What worked? What didn’t? How do we

fix the latter next time? How accurate was our estimation? Was the customer happy? Did the project meet its success criteria?


Party!

Sounds trite, but celebrating team success is very valuable Tokens from the project (mugs, T-shirts,

etc.) can provide a connection for years afterward, even if you can’t afford five digit bonuses for everyone

Oodles (that’s a lot) of loyalty and motivation can come from showing genuine appreciation

Documents

Software Project Management