Project Management CTC-ITC 310 Fall 2018 Howard Rosenthal

Transcription

1 Project Management CTC-ITC 310 Fall 2018 Howard Rosenthal

2 Notice This course is based on and includes material from the text: A User s Manual To the PMBOK Guide Authors: Cynthia Stackpole Snyder Publisher: Wiley ISBN: , Copyright 2013 It also utilizes general information and figures from the PMBOK: A Guide to the Project Management Body of Knowledge (PMBOK 5 TH Edition) Publisher: Project Management Institute ISBN: , Copyright 2013 and A Guide to the Project Management Body of Knowledge (PMBOK 6 TH Edition) Publisher: Project Management Institute ISBN: , Copyright 2017 The course also includes and intersperses some materials, most often diagrams, provided by Mr. Wysocki s PowerPoint slides, at the website: And the book Effective Project Management - Traditional, Agile, Extreme 7TH Edition Authors: Robert K. Wysocki Publisher: Wiley ISBN: , Copyright

3 Lesson Goals What are the immutable processes in any project What are the different project management models Traditional Project Management (TPM) Agile Project Management (APM) How do you pick the best lifecycle models within a project management framework Predictive Iterative Incremental Agile-Adaptive Adaptive and Agile are often used synonymously in the PMBOK Describe Development-Operations (DevOps) 3

4 4

5 Project Management Processes and Phases A Project Management Life Cycle is a series of processes that include: Initiating Process Planning Process Executing Process Monitoring and Controlling Process Closing A project phase, which culminates in one or more deliverables, will go through each of the above steps at least once. Various project phases that are used in a product include some or all of the following: Concept Development Feasibility Study Requirement Development Prototyping Architecture and Design Deployment Closure A project phase includes: Name Duration Resource requirements Entrance and exit criteria The order of the steps and the number of iterations/increments/cycles depends on the life cycle that is chosen 5

6 Definable Work vs. High-Uncertainty Work Project work ranges from well defined to highly uncertain Different life-cycle models may be employed based on the degree of uncertainty Example of well defined work may include those with reproducible processes and outcomes Installing new wiring or computer systems using off-the-shelf products Mass production of Army boots High-uncertainty projects have less well-defined requirements, require technical advances, or are subject to changing priorities Building a space telescope Creating the first iphone Implementing upgrades and new features in an IT project amidst changing priorities and limited resources Changing weapons design as battlefield conditions evolve (i.e. Humvee design) 6

7 Project Management Life Cycles A project lifecycle is the series of phases that a project passes through from start to finish. Phases may be sequential, repetitive or even overlapping The PMI defines four life cycle models Predictive life cycle A traditional approach with most planning occurring before the actual development begins. The waterfall model is the best example Iterative life cycle Allows for feedback and modification during the development to improve the product before it is released Incremental life cycle Finished deliverables are provided and then a new increment starts over. Agile life cycle (sometimes called adaptive) An approach that refines work and delivers new capabilities on a regular basis. Similar to Incremental but more rapid turn around. The development team gets early feedback and interacts with customer on a continuous basis to obtain feedback. Early return on investment helps keep the project going. Hybrid life cycles are a combination of the above life cycles Most projects aren t completely pure The type of project you are working on will impact the type of management life-cycle approach that you adopt 7

8 Planning Is A Part Of Any Life Cycle Much of project management involves planning Every life cycle model requires planning The difference between life cycles is how much planning is done, and how often it is done Predictive Most planning is done once, up front Plan drives the work Requirements are all defined up front Iterative Includes prototypes and proofs that may lead to modification of the original plan However there is still one big delivery at the end Incremental Actual deliveries are planned in advance, perhaps one at a time or in succession Goal is to deliver pieces of the project for an initial use or some other reason Agile The key difference here is the team plans and replans at the end of each cycle. The cycles are usually very short The next delivery will be determined based on project priorities and available resources 8

9 Project Management Types and Associated Life Cycles There are two different Project Management Types that employ different life cycle models Tradition Program Management (TPM) Predictive and Iterative Life Cycle Models Used when the goal and solution are clear 20% of all projects Example Install a network in a building Agile Program Management Incremental and Agile Life Cycles Models Used when the goal is clear but the solution is not Used when the final goal is changing so that the solution must evolve due to market changes, technological advancement, business needs, etc. 80% of all projects Example Send a crew of 5 to Mars and return them safely to Earth before

10 Picking The Correct Life Cycle Model PMBOK V6 Agile Fig

11 The Life-Cycle Continuum PMBOK V6 Agile Fig

12 Differences In The Project Life Cycles PMBOK V6 Agile Table

13 13

14 Traditional Program Management (1) Predictive Life Cycle Model PMBOK V6 Agile Fig. 3-2 Characteristics Of Good Use Of The Predictive Life Cycle Well understood and defined requirements with constraints identified Lower complexity Low risk Serial execution of the project in accordance with the plan Widely used Experienced and skilled project teams Well-understood technology infrastructure Leader minimizes change during the project Should not be used for research or development projects Changes can lead to unanticipated costs 14

15 Traditional Program Management (2) Iterative Program Management Life Cycle Model PMBOK V6 Agile Fig. 3-3 Characteristics Of Good Use Of The Iterative Life Cycle Successive prototyping Prototyping leads to lowered risk during development New information incorporated based on learning experience Recognizes the complexity of some projects and identifies and solves unknowns iteratively Experienced and skilled project Teams Still has a single plan up front, but it is more of an outline that is progressively elaborated as more data becomes available 15

16 Advantages And Disadvantages of TPM Projects Advantages Easy to understand and implement. Widely used and known (in theory!). Reinforces good habits: define-before- design, design-before-code. Identifies deliverables and milestones. Document driven, User Requirements Document (URD), Systems Requirements Document (SRD),... etc. with published documentation standards Works well on mature products and weak teams Disadvantages Idealized view Doesn t match reality well Doesn t reflect iterative nature of exploratory development. Unrealistic to expect accurate requirements so early in a project, especially a large complex project Often leads to cost overruns Replanning and rebaselining not included Software is delivered late in project, delays discovery of serious errors Difficult to integrate risk management Difficult and expensive to make changes to documents, Significant administrative overhead, costly for small teams and project 16

17 Differences Between The Predictive And Iterative Life Cycle Models The predictive model holds the contractor s feet to the fire Must live within baselined cost and schedule No rework is expected The structure of the Iterative PMLC model encourages change based on experience The initial release of a partial solution gives the client and the end user an opportunity to experiment with the partial solution in a production scenario and find areas that could be improved encouraging change requests The full solution is decomposed into partial solutions whose development would then be implemented in a sequential fashion However, there is no replanning in this model even though there will undoubtedly be changes to the design and implementation based on the results of prior iterations The release schedule needs to be consistent with the dependencies that exist between each partial solution especially if there is parallel development 17

18 Classic TPM Is The Waterfall Model 18

19 The Waterfall In Reality In reality there are almost always unknowns and changes This leads to the potential to circle back at any step to a prior step in the life cycle 19

20 The V-Shaped Model Is A TPM Variation On The Waterfall Advantages Disadvantages Higher chance of success over the waterfall model due to the early development of test plans during the life cycle Software is developed during the implementation phase, so no early prototypes of the software are produced Each phase has specific deliverables Little flexibility and adjusting scope is difficult Simple and easy to use Very rigid like the waterfall model Works well for small projects where requirements are easily understood This model does not provide a clear path for problems found during testing phases 20

21 The Spiral Model Combines The Traditional/Predictive Lifecycle Model With Prototyping It Is Iterative 21

22 The Spiral Model Follows A Path That Leads To Requirements Discovery (1) The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure: Evaluating the first prototype in terms of its strengths, weaknesses, and risks Defining the requirements of the second prototype Planning and designing the second prototype Constructing and testing the second prototype. 22

23 The Spiral Model Follows A Path That Leads To Requirements Discovery (2) At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime. 23

24 Advantages And Disadvantages Of The Spiral Model Advantages High amount of risk analysis Good for large and mission-critical projects Software is produced early in the software life cycle Disadvantages Can be a costly model to use Doesn t work well for smaller projects Project s success is highly dependent on the risk analysis phase Risk analysis requires highly specific expertise 24

25 25

26 Agile Project Management (1) Scope Incremental Life Cycle Model Plan Increment Launch Increment Monitor & Control Close Increment Next Increment No Close Project Yes PMBOK V6 Agile Fig. 3-4 Characteristics A previously untapped business opportunity Early delivery of a partial solution new features can be added later Initial deliverables planned at project onset later deliverables defined as project evolves Critical to the organization Meaningful client involvement is essential Use small co-located teams 26

27 Agile Project Management (2) Agile/Adaptive Life Cycle Model Characteristics Really very similar to incremental Each Agile iterative/incremental cycle helps uncover new requirements Fulfills the Agile Manifesto (see next section) Requirements not fully understood at outset Meaningful client involvement is essential Customer satisfaction increases with early and continuous delivery of new value this keeps the project sold 27

28 Comparing The Incremental and Agile/Adaptive Life Cycles (1) Incremental life cycles are ones in which project phases intentionally repeat one or more project activities as the project team s understanding of the product increases However, the entire scope of the project is defined up front The Incremental Life Cycle is used for projects where change in the scope needs to be managed In this life cycle a plan is detailed for the near-term increments and a high level vision is created for rest New plans are detailed for each increment In this approach project phases proceed through sequential or overlapping modes in every increment Change during the project is naturally handled in upcoming increments The end result is delivered at the end of each increment For instance, yearlong project will have 3 months increments and each increment will execute Planning, Analysis, Design, Code, Testing phases and deliver the result at the end of the increment The difference between the incremental life cycle and the adaptive/agile life cycle is that the increment life cycle allows for longer spans of time between deliveries, while each cycle in the adaptive life cycle is typically 2 to 4 weeks Note: Remember that PMBOK and others use Agile and adaptive interchangeably at times 28

29 Comparing The Incremental and Agile/Adaptive Life Cycles (2) Adaptive life cycles are intended to respond to high levels of change and ongoing stakeholder involvement. This life cycle is used for projects where changes are expected and scope is not possible to define up front In this life cycle model scope is decomposed into a set of requirements known as product backlog and getting picked as per priority from the set in every cycle With this, project phases proceed through sequential or overlapping mode in every cycle (to distinguish from iteration) Change during the project is naturally handled in rapid cycles. The end result is delivered at the end of each 2-4 week cycle E.g. a yearlong project will have multiple 2-4 week cycles and each cycle will execute Planning, Analysis, Design, Code, testing phases and deliver the result at the end of the cycle The Adaptive life cycle is the one most often associated with the term Agile 29

30 Iteration-Based and Flow-Based Agile PMBOK V6 Agile Fig

31 Iteration-Based v. Flow-Based Agile Both iteration-based and flow-based Agile follow the principles of the Agile Manifesto Customer satisfaction increases with early and continuous delivery of new value-added products Very popular in established IT world Iteration-Based Agile Teams work in time-boxes of equal duration to deliver completed features Features are defined so that they fit in the time-box Team works on most important feature collaborating as a team It is possible to put multiple requirements in an Agile increment, but not all (that would be waterfall) Flow-Based Agile Team pulls features from a backlog (queue)based on its capacity to start the work rather than based on the schedule Considerations include not just priority but availability of human and physical resources For instance, you may need to test a part, but can only do so when the test facility is available Different features may require different amounts of time to finish Still try to keep the features small enough to allow a continual pipeline of value-added features 31

32 Advantages And Disadvantages Of The Agile Model Advantages Customer satisfaction by rapid, continuous delivery of useful software. People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other. Working software is delivered frequently (weeks rather than months). Face-to-face conversation is the best form of communication. Close, daily cooperation between business people and developers. Continuous attention to technical excellence and good design. Regular adaptation to changing circumstances. Even late changes in requirements are welcomed Disadvantages In the case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle. There is lack of emphasis on necessary designing and documentation. The project can easily get taken off track if the customer representative is not clear what final outcome that they want. Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources. Upper management loves certainty and earned-value measurement which can only be easily measured for the increment being created 32

33 33

34 Hybrid Life Cycle Models Many programs combine different approaches based on the nature of the activity Some programs involve both well-defined and less welldefined elements Research and development often uses the spiral model, with subsequent development done in an incremental or Agile fashion The deployed infrastructure may be more well-defined, allowing the underlying infrastructure to be deployed following a waterfall model Many-times the programs spins off subprojects run with different models Tailoring of project life cycles often occurs to improve the fit 34

35 Tailoring Options May Be Based On Different Project Factors and Priorities (1) PMBOK V6 Agile Table X2-1 35

36 Tailoring Options May Be Based On Different Project Factors and Priorities (2) PMBOK V6 Agile Table X2-1 (Cont.) 36

37 Tailoring Options May Be Based On Different Project Factors and Priorities (3) PMBOK V6 Agile Table X2-1 (Cont.) 37

38 38

39 As The Degree Of Uncertainty Increases The Appropriate Management Model Evolves From the Predictive To Highly Adaptive The models form a natural ordering (Predictive, Iterative, Incremental, Agile/Adaptive) by degree of solution uncertainty The processes that form repetitive groups recognize the effect of increasing uncertainty as you traverse the natural ordering Those groups move more toward the beginning of the life cycle as uncertainty increases Complete project planning is replaced by just-in-time project planning as the degree of uncertainty increases Risk management becomes more significant as the degree of solution uncertainty increases The need for meaningful client involvement increases as the degree of solution uncertainty increases. 39

40 Selecting The Right PMLC Predictive (TPM) Clearly defined solution and requirements Not many scope change requests expected Routine and repetitive projects Uses established templates Iterative (TPM) Same as predictive but delivers business value early and often Some likelihood of scope change requests Incremental (Agile Management) Unstable or or incomplete requirements and functionality Learn by doing and by discovery Adaptive (Agile Management) Goal known but solution not known Solution highly influenced by expected changes New product development and process improvement projects 40

41 Additional Factors In Selecting The Right PMLC (1) Total Cost As the total cost of the project increases, so does its business value and so does its risk. Losses are positively correlated with the total cost, so you should be able to justify spending more on your mitigation efforts than you would for a project of lesser cost. Need to place more emphasis on the risk management plan than is called for in the chosen model. Appoint a separate Risk Manager Duration A longer duration project brings with it a higher likelihood of change, staff turnover, and project priority adjustments. Pay more attention to your scope change management plan and the Scope Bank The Scope Bank contains all of the suggested ideas for change that have not been acted upon and the total labor time available for their integration into the solution. Put more emphasis on the mitigation plans for dealing with staff turnover. Market Stability One way to protect the project would be to implement deliverables incrementally. Shorter increments might make sense. As each increment is implemented, revisit the decision to continue or postpone the project. Ultimately determine if earlier product release makes sense. Technology Technology is changing at an increasing rate Difficult to keep up with it Difficult to leverage it to your best advantage If the new technology will leverage you in the market, you might want to wait but make sure you can integrate it when it is available. Rapid response is to your advantage. 41

42 Additional Factors In Selecting The Right PMLC (2) Business Climate The more volatile the business climate, the shorter the total project duration should be. For APM projects, the cycle time boxes could also be shorter than typically planned. Partial solution releases will have a higher priority than they would in business climates that are more stable. Number of Departments Affected As the number of departments that affect or are affected by the project increases, the dynamics of the project change. The requirements needs of several departments will have to be taken into account. Could lead to scope creep during the project scoping process as each department will have its list of must haves and wouldn t it be nice to haves. Higher incidence of needs contention, which means the needs from two or more departments may contradict one another. Must resolve the conflicts as part of validating requirements. Organizational Environment If your company announces reorganizations and changes in seniormanagement responsibilities quite frequently you have a problem. The single most-frequent reason for project failures as reported in the past several Standish Group surveys is lack of executive-level support, including loss of support resulting from company reorganization. If you had a sponsor who was very enthusiastic about your project, and a strong and visible champion for you, and who has been replaced, how the new sponsor feels is critical to continued project success. 42

43 Material for this section is drawn from: 43

44 What Is DevOps DevOps is a culture which promotes collaboration between Development and Operations Team to deploy code to production faster in an automated & repeatable way The word 'DevOps' is a combination of two words 'development' and 'operations DevOps helps to increase an organization's speed in delivering applications and services It allows organizations to serve their customers better and compete more strongly in the market. In simple words, DevOps can be defined as an alignment of development and IT operations with better communication and collaboration 44

45 DevOps Management Principles Customer-Centric Action DevOps team must take customer-centric actions that by constantly investing in products and services End-To-End Responsibility The DevOps team needs to provide performance support until end-oflife for the system. Continuous Improvement DevOps culture focuses on continuous improvement to minimize waste. It continuously speeds up the improvement of products or services offered. Automate Everything Automation is a vital principle of DevOps process. This is not only for the software development but also for the entire infrastructure landscape. Work As One Team In the DevOps culture the roles of the designer, developer, and tester are already defined. All they needed to do is work as one team with complete collaboration. Monitor and Test Everything It is very important for DevOps team to have robust monitoring and testing procedures. 45

46 When Is DevOps Needed? Before DevOps, the Development Team and Operations Team worked in complete isolation Testing and Deployment were isolated activities done after design-build. Hence they consumed more time than actual build cycles. Without using DevOps, team members are spending a large amount of their time in testing, deploying, and designing instead of building the project Manual code deployment was leading to human errors in production Coding & operation teams have their separate timelines and are not in synch causing further delays 46

47 Comparing DevOps and Older Processes Older Process After placing an order for new servers, the Development team works on testing. The Operations team works on extensive paperwork as required in enterprises to deploy the infrastructure. Projection about failover, redundancy, data center locations, and storage requirements are skewed as no inputs are available from developers who have deep knowledge of the application. Operations team has no clue on the progress of the Development team. Operations team develop a monitoring plan as per their understanding. Before go-live, the load testing crashes the application. The release is delayed. DevOps After placing an order for new servers Development and Operations team work together on the paperwork to set-up the new servers. This results in better visibility of infrastructure requirement. Projection about failover, redundancy, disaster recovery, data center locations, and storage requirements are pretty accurate due to the inputs from the developers. In DevOps, the Operations team is completely aware of the progress the developers are making. Operations team interact with developers and jointly develop a monitoring plan that caters to the IT and business needs. They also use advance Application Performance Monitoring (APM) Tools. Before go-live, the load testing makes the application a bit slow. The development team quickly fixes the bottlenecks. The application is released on time. 47

48 Why Is DevOps Used? (1) Faster to market DevOps allows Agile Development Teams to implement Continuous Integration and Continuous Delivery that helps them to launch products faster into the market DevOps reduces the time to market up to 50% through streamlined software delivery This is particularly the case for digital and mobile applications Predictability DevOps offers significantly lower failure rates with new releases Reproducibility Version everything so that earlier version can be restored anytime Maintainability Effortless process of recovery in the event of a new release crashing or disabling the current system 48

49 Why Is DevOps Used? (2) Improved Quality DevOps helps the team to provide improved quality of application development as it incorporates infrastructure issues Reduced Risks DevOps incorporates security aspects in the software delivery lifecycle It helps in reducing defects across the lifecycle. Resiliency The operational state of the software system is more stable and secure, and changes are auditable. Cost Efficiency DevOps offers cost efficiency in the software development process which is always an aspiration of an IT companies' management Breaks larger code base into small pieces DevOps is based on the Agile programming method, allowing for the breaking of larger code bases into smaller and manageable chunks 49

50 When To Use DevOps DevOps should be used for large distributed applications such as ecommerce sites or applications hosted on a cloud platform DevOps should not be used in a mission-critical application like bank, power and other sensitive data sites Such applications need strict access controls on the production environment, a detailed change management policy, access control policy to the data centers 50

51 The Continuous Development Life-Cycle Development In this DevOps stage the development of software takes place constantly The entire development process is separated into small development cycles allowing the DevOps team to speed up the software development and delivery process Testing The QA team uses tools to identify and fix bugs in any new piece of code. Integration In this stage, new functionality is integrated with the prevailing code, and testing takes place Continuous development is only possible due to continuous integration and testing. Deployment In this phase, the deployment process takes place continuously It is performed in such a manner that any changes made any time in the code, should not affect the functioning of high traffic websites Monitoring In this phase, operation team will take care of the inappropriate system behavior or bugs which are found in production 51

52 The DevOps Lifecycle 52

53 Comparing Agile and DevOps Agile Emphasize breaking down barriers between developers and management Addresses gap between customer requirements and development teams Focuses more on functional and non-functional readiness Agile development pertains mainly to the way development is thought out by the company Agile development puts a huge emphasis on training all team members to have varieties of similar and equal skills When something goes wrong, any team member can get assistance from any member in the absence of the team leader Agile development manages on "sprints. It means that the time table is much shorter (less than a month) and several features are to be produced and released in that period DevOps DevOps is about software deployment and operation teams Addresses the gap between the Development Team and the Operation Team It focuses operational and business readiness DevOps emphasis is on deploying software in the most reliable and safest ways which aren't necessarily always the fastest DevOps, likes to divide and conquer, spreading the skill set between the Development Team and Operation Team It also maintains consistent communication between the stakeholders DevOps strives for consolidated deadlines and benchmarks with major releases, rather than smaller and more frequent ones 53

54 The Roles, Responsibilities and Skills Of The DevOps Engineer (1) A DevOps Engineer is an IT professional who works with software developers, system operators, and other production IT staff to administer code releases. A DevOps Engineer should have hard as well as soft skills to communicate and collaborate with development, testing, and operations teams. A DevOps engineer will work with development team staff to tackle the coding and scripting needed to connect elements of code, like libraries or software development kits. 54

55 The Roles, Responsibilities and Skills Of The DevOps Engineer (2) The DevOps engineer: Is able to perform system troubleshooting and problemsolving across platform and application domains. Manages a project effectively through open, standards-based platforms Increases project visibility thought traceability Improves quality and reduce development cost with collaboration Analyzes, designs and evaluates automation scripts & systems Ensures critical resolution of system issues by using the best cloud security solutions services (for certain applications) 55