1 / 10

Planned and Unplanned Adjustments/Actions

Planned and Unplanned Adjustments/Actions. Taking actions with a sense of “ urgency ” is important sets a tone as a project manager , who is responsible cares is committed Sequence of 6 mini-actions (steps) within the adjustment process

fatima-ortega
Télécharger la présentation

Planned and Unplanned Adjustments/Actions

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. Plannedand Unplanned Adjustments/Actions • Taking actions with a sense of “urgency” is important • sets a tone as a project manager , who • is responsible • cares • is committed • Sequence of 6 mini-actions (steps)within the adjustment process • clarify, understand, and clearly state theproblem(*important step*) • communicate the problem while working on potential solution(s) • gain necessary agreement for the “chosen” solution • act on the solution • simultaneously along with item (4), communicate on the action(s) taken • report on the resolution status

  2. “Planned” Adjustments • Anticipatory within a software process that includes: • Prototype- and – make “necessary” Changes • Reviews- and – make “correctional” Changes • Test - and – make “correctional” Changes • Consider the following simple set of activities, where would you have built-in, planned changes? --- • Requirements • Design • Code • Test • Integration

  3. Planned Adjustments • The goal is NOT to have big “surprise”; make adjustments that are: • incremental • small • Three “basic” project attributes should be visited, but with planned, incremental adjustments to: • Functionality • Resource(s) • Schedule • Example: • bringing in “additional” resources (tool or people) for a later phase that was caused by an incremental change in the previous phase.

  4. “Special” Planned Adjustments Example • Quality (mostly defects) Attribute: • not “compromisable” • Planned lessening of functionality but not delivering a defective function: • Non-Context Sensitive Help or no Help at all • Less important “vertical” and separable functions (horizontal functions are cross product and harder to separate) • Less “nice” to have vertical functions • Shorter error messages with less error reason or recovery hints • Planned increase in schedule • Planned increase in resources

  5. Planned (anticipated) Adjustments & “Risks” • Should/May be listed as potential “risks” resulting from • Prototyping • Reviews/inspections • Testing • Mitigation for the above would have been: • Buffered resource • Buffered schedule • Lowering commitment on requirements

  6. “Unplanned” Adjustments/Actions • Mostly responding tounanticipatedand often large in size problem that impacts one of the 3 main attributes and possibly 4th (Quality): • Schedule • Resource(s) • Functionality (requirements)

  7. Functionality Impact • Consider the amount of increase or decrease to • resources • schedule • Consider the inter-relationship of resource and schedule: (e.g.) “more functionality”=> more schedule --- but how about resources ?: • adding resources may “further” expand schedule!; (perhaps change of resources ?) • The timing of change • lesser impact during earlier phases • the later phases impact may cause large adjustments • causes “re-do” of all the earlier activities related to the change • increase or modify planned, downstream activities Also --- Watch out for internal “scope creep” of functions

  8. Resource impact • Consider the amount of increase or decrease to • schedule • functionality • Consider the interrelationship of schedule and functionality: (e.g.) “less resources” => more schedule but how about functionality ?: • taking out functionality or partially completed functionality may cause more work and lengthen the schedule even more (minimally needs “retest’ of previously working parts) • Timing of & Type of Change makes a difference • more impact on “key” resources e.g. – 1) losing key designer during design stage or 2) heavy system (tools, network, hardware) “downs” during coding/debugging or functional test phases Watch out for late additions of “new” resource --- may slow you down more

  9. Schedule Impact • Very, very rarely do we have an elongation of schedule; most likely it is “shortening” of schedule • Consider the amount of increase or decrease to • resources • functionality • Consider the inter-relationship of resources and functionality: (e.g.) less time => more other resources (mostly people) & less functions?) • adding resources that need training can further impact time and functionality (possibly perform some in-depth CPM “trade-offs”) • adding resources with “correct” knowledge/skill may even net more functions • Consider the timing: • Early phases of software development can handle schedule shortening easier • Well planned testing may be handled in parallel, allowing schedule shortening Some tasks can not be shortened ---- no possible overlapping

  10. Inter-Related: 3-main Project Attributes Functionality Resources Schedule A push on any one vertex may “re-shape” the triangle

More Related