110 likes | 300 Views
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
E N D
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
“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
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.
“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
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
“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)
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
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
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
Inter-Related: 3-main Project Attributes Functionality Resources Schedule A push on any one vertex may “re-shape” the triangle