1 / 44

Software Project Management

Software Project Management. Team management and project closeout INFO 638 Glenn 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

clyde
Download Presentation

Software Project Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Project Management Team management and project closeout INFO 638 Glenn Booker Lecture #6

  2. 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 Lecture #6

  3. 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 Lecture #6

  4. 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 Lecture #6

  5. 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 Lecture #6

  6. 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 Lecture #6

  7. 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 Lecture #6

  8. 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 Lecture #6

  9. 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? Lecture #6

  10. 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 Lecture #6

  11. 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 Lecture #6

  12. 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) Lecture #6

  13. 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! Lecture #6

  14. 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 Lecture #6

  15. 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 Lecture #6

  16. 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 Lecture #6

  17. 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 Lecture #6

  18. 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 Lecture #6

  19. Contract Team Recruiting • 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 Lecture #6

  20. Contract Team Recruiting • 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 Lecture #6

  21. 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 Lecture #6

  22. 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 Lecture #6

  23. 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 Lecture #6

  24. 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 Lecture #6

  25. 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 Lecture #6

  26. 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 Lecture #6

  27. 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 Lecture #6

  28. 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 Lecture #6

  29. 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 Lecture #6

  30. 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.) Lecture #6

  31. 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 Lecture #6

  32. 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 Lecture #6

  33. 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 Lecture #6

  34. 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 Lecture #6

  35. 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? Lecture #6

  36. Project Closeout Lecture #6

  37. 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! Lecture #6

  38. 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 Lecture #6

  39. 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 Lecture #6

  40. 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 Lecture #6

  41. 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 Lecture #6

  42. 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”) Lecture #6

  43. 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? Lecture #6

  44. 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 Lecture #6

More Related