discuss your understanding of “PM YOU” field test two content that was provided for you. 1 page is good.
6. PM you … Field Test 2 6.1. Overview This field examines the following topics with respect to real-world project management: Just because the last project was a Success | Failure does not necessarily mean that the next project will turnout the same way. Start each project logically & methodically from a “clean slate” beginning. For a ‘Fixed Price’ contract project, a fair amount of the Planning Phase may need to be conducted during the Initiating Phase. Determining the [Scope], what will and will not be given to the customer. Determining the [Time], how long it is expected to take to conduct the proposed project. ᴏ Project schedule layout, contents & components, feasible estimations. ᴏ Spreading the partial payment milestones for a “positive cash flow”. ᴏ Integrating the project schedule into the Program Roadmap. Determining the [Cost] and what is the expected budget to conduct the proposed project. ᴏ Calculating the overall budget based on the schedule’s determined Level Of Effort, the inclusion of burdens & margins (i.e. safety, management, profit). Importance of multiple acceptance testing over the duration of the implementation and delivery lifecycle. 6.2. Introduction The Success | Failure of one project does not make or break the validity of your personalized project management techniques (i.e. “PM you”); as it needs to evolve based on the trials & tribulations of those real-world SDLC project that you encounter. 6.2.1. The Scenario So, onto the next project, the ‘Fixed Price’ development of a new system from concept to production rollout. Though, the question still remains, hidden in the back of your self-evaluating mind, as to whether your recent setback on your previous project will be a forbearer of bad tidings for this newly assigned project. … “Given that, your past technical expertise was no real predictor of your successes and failures on that project.” Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 44: Just because your last project was a success (or a failure) does not necessarily mean that your next project will also be a success (or a failure). RULE 44A: Each project has its own unique set of project variables & constraints; as well as differences in the situation & prevailing circumstances. “The reality is, no matter how skilled the Project Manager and the Project Team, sometimes bad things do happen. The cause of the project’s failure may have been within their grasp, or it may have been outside of their control. The important thing now is to have some idea of what went wrong, why it went wrong; and hopefully, learn from this, so as to minimalize the potential occurrence of those bad things in the future.” As demonstrated in Field Test 1 , a project can fail for many and varied reasons, however, for now, the important thing is to “learn the lessons from the past” so that the Success | Failure of the next project is not left simply to chance. Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 45: Learning from your mistakes is smart; but, learning from the mistakes of others is wise. 6.2.2. Beginning From A Clean Slate As per the previous project, start the new project with what apparently worked: 1.. Building that first impression of the project, the performing organization, the Project Implementation Team, and you as the Project Manager. 2.. Answer those opening questions that will define the new project based on the ‘needs & wants’ of the customer, evaluate the viability of the proposed project, and then obtain formalized approval and authorization to commence the project. That is, create the Project Charter and get it signed off, so as to begin in earnest. 3.. Based on the [Scope] Boundary of work uncovered thus far, estimate a Rough Order of Magnitude for the project’s [Time] duration and the “Level Of Effort” involved, and the example case … Calculate the Overall Budget [Cost] including the Management Reserve and Profit Margin, ; though, try to ensure that the project is not priced to death. 6.3. And, So, It Begins 6.3.1. What Do They Want? During the project’s Initiating Phase, the customer’s requirements (including the associated notes and reference materials) should be accumulated for the representatives of the customer & performing organizations to come together to review, explain, and discuss. Subsequently, there should be an understanding as to the customer’s “perceived benefits”, “desired outcomes”, and “expected business changes” from conducting this project; as ideas should be forming with respect to the primary Use Cases that will need to be implemented in order to satisfy the customer’s “needs & wants”. And, hopefully by now, the representatives from both the customer & performing organizations (are starting to) have a “common understanding” and mental alignment” with respect to; the interpretations of the requirements, what are the desired deliverables, the intended milestones, and the scale of the project to be undertaken. Which is all then summarized in the Project Charter. 6.3.2. What’ll We Give & Not Give To Them? With the Customer Requirements now having been agreed to, for the purpose of intent, being not binding on either the performing & customer organizations (a “wish-list” per se); then the performing organization would put together a high-level list of “what will & won’t be delivered”. Depending on the situation and industrial circumstances, this response may be included as part of the Project Charter (with the level of detail as per a glossy sales & marketing brochure), or it may be stipulated that it be expanded upon as a feature-by-feature list with appropriate levels of explanation in a Detailed Specifications (aka Functional Specifications – FS, Detailed Business Requirements Specifications – DBRS). In some situations, this Detailed Specifications document may be incorporated into the response to a Request For Tender (RFT), a Request For Proposal (RFP), or a Request For Quotation (RFQ). Whatever form and wherever this document resides, the level of technical detail within this specifications should be sufficient to provide the Customer’s Representatives with enough confidence that the performing organization understands what is being asked of them, that they demonstrate a level of knowledge sufficient for the proposed endeavor, and that they have a good idea as to what needs to be done. … Without committing the performing organization to what could be (in hindsight) a mistaken technical specification. Subsequently, the creation of this (Detailed) Specifications would involve the Business Analyst (BA), the Systems Architect (SA), and relevant Subject Matter Experts (SME) working together with the Project Manager (PM), … and, senior implementers, so that realistic & technically feasible solutions are considered and summarized; instead of the technically unachievable being proposed (by Sales & Marketing | Business Department). While defining the (Detailed) Specifications, the Proposed Manager could cross match the Customer Requirements with the features & functionality point entries in the Requirement Traceability Matrix (RTM) spreadsheet, so as to ensure the coverage of “what’s in, what’s out, and what needs to be decided upon” is recorded for clarification. At this point, depending on the project’s payment method to be utilized (i.e. ‘Fixed Price’, ‘Time & Materials’, or ‘Cost Reimbursement’), then different levels of due diligence consideration would be given to determining the proposed project’s [Time] & [Cost]. However, there firstly needs to be some understanding as to how does this project (and the deliverables) fits into the “big picture” (overall scheme) of what the customer & performing organizations are trying to accomplish; i.e. where the project fits into the Program of Work. Noting that, both organizations, at any given time, only have certain quantities of capital [Cost], [Time], [People] & [Resources] at their disposal; thus, would the organization be strategically better served to pay to use other organizations’ capabilities & capacities rather than utilizing their own, or forgoing this project entirely? Program (or Work) … is where multiple projects are coordinated to contribute towards achieving a common business objective. Portfolio … is where a collection of projects & programs are coordinated to achieve the organization’s “strategic goals” (i.e. greater business objectives). Project Charter This project is the first stage of a multi-staged program of work, the stages being; (1) deployment of the baseline functionality, (2) customization of the provided solution with advanced features, (3) future enhancements that have yet to be defined as these will most probably be defined once stage 1 is completed and Stage 2 is underway. Where each stage will not commence until the predecessor stage has been signed off as successfully delivered. The project for Stage 1 has been broken up into the following major activities: Analysis and design of the system integration. Application development on an in-house test platform. Functional Acceptance Test (FAT) using the in-house test platform. Deployment into the customer’s “Ready For Deployment” network, and Satisfaction Acceptance Test (SAT). Deployment into the customer’s “Ready To Go Live” network, and Usability Acceptance Test (UAT). Public Go Live activity which is to occur on Monday 31-10-2015. Stage 2 and Stage 3 are out-of-scope of this Project Charter’s Statement Of Work. Helpdesk support training will not be included as part of the Stage 1 deliverables. The associated Administration & Maintenance Manuals and Help Desk Support Guides will not be included as part of the Stage 1 deliverables. The performing organization is only responsible for providing the FAT testing facility; all other testing facilities will be provided, supported, and maintained by the customer organization. The Stage 1 project milestones and associated partial payment milestones have been agreed to align with the culmination of those major project activities listed. Given that this scenario’s project is going to be a ‘Fixed Price’ contract with a stipulated End Date (when the first release of the resultant product deliverable must go live), then this project’s Initiating Phase will need to incorporate a relatively detailed amount of planning that would normally be done during the Planning Phase. In Depth Planning Conducted During The Initiating Phase In looking on the project life cycle and on the PMBOK theory, there was presented a relatively straight forward relationship of the project’s Initiating Phase flowing into the project’s Planning Phase. However, for some projects, specifically those involving a ‘Fixed Price’ contract, then much of the detailed planning (i.e. the Detailed Specifications, and the Architectural Design) may need to be undertaken during the Initiating Phase so as to produce a detailed Project Schedule, and thereby calculate an accurate Overall Budget | Contract Price. For a ‘Fixed Priced’ contract then due diligence [Time] & [Costs] estimates are necessary; however, these can only be determined by having a good understanding of the project’s [Scope] and with the realistic allocation of the [People] & [Resources] that would be required for the implementation & delivery to occur. Whereas, for ‘Time & Materials’ or ‘Cost Reimbursement” based project then the quoted price only needs to be within at least 20-25% range of that which would be produced by a relatively detailed analysis; i.e. a Rough Order of Magnitude (ROM). 6.3.3. How Long Is It Expected To Take? 1st Pass Schedule During this Initiating Phase, Senior Implementers (and PM) should transform those initial ideas & concepts of the project’s composition into modularized Architectural Design sketched of how this thing should probably go together; thereby, determining the constituent parts as denoted in the Work Breakdown Structure (WBS). … And hopefully, aligning the project management [Time] Schedule and subsequent [Cost] Budget with the implementers’ perspective of how the [Scope] can be delivered. Thus, with the aid of the BA – SA – SME – Implementers, progressively elaborating the 1st Pass schedule to determine the major work activities to be done. “Wow Man, that is such a way-out there radical idea to get the implementers involved with helping to determine the estimates for those technical & productions activities; instead of having non-technical people guesstimating (or some would say, ‘randomly selecting’) the Time, People and Resources involved with such area of technical expertise.” 2nd Pass Schedule With the 1st Pass Schedule having taken form (though containing no actual start dates nor end dates, no named allocations of people & resources, and no real task duration estimations), just the listing of all of the major activities and the identification of the primary Use Cases that will need to be done. Then, with the aid of the BA – SA – SME – Implementers, a 2nd Pass Schedule (with the sequencing & parallelizing of tasks) should be produced, focusing on the relatively accurate estimation of the Level Of Effort involved with each of those identified major activities and primary Use Cases. Suggest, using a technique such as ‘Weighted Average’ where the senior implementers | SME provide for each task an estimate of; (t0) optimistic best case, ™most likely normal case, and (tp) pessimistic worst case. (t0 + 4tm + tp) = Weighted Average While this ‘Weighted Average’ calculation does provide more realistic estimates than the simple putting forward of single values, this technique is a bit more pessimistic with its numbers. Have a Wiki at, PERT – Project (Program) Evaluation Review Technique. I would recommend that, the Project Manager obtain as accurate as possible estimates for task duration and Level Of Efforts [Time], because these estimates will directly affect the project’s [Cost] budget calculation. When obtaining estimates for task durations | Level of Effort, then: DO NOT accept too long a duration | effort estimate for a single task, because when this long duration | effort task is broken down into its constituent parts then the resultant child-tasks often increase or decrease the parent-task’s length to something closer to what really will be required for its implementation. “Most people are prone to giving overly optimistic estimates; while, others may give as big an estimates as they think will be accepted (as a form of their own private safety buffer), and others will provide estimates that they think the asker wants to hear.” DO NOT seek to small a duration | effort estimate for a single task, because too fine a granularity will result in micro-managing the [People] and an overly complex and bulky schedule. Instead, go to the level of tasks that are apparent steps towards a deliverable and not down to the minor along the way. Set a maximum limit on the estimated duration | effort for any individual task (e.g. 80 hours) anything quoted as longer than this duration has to be broken down into shorter duration sub-tasks. Though, if the project is a of a relatively short duration (e.g. one month) then the maximum estimation limit per task maybe set as a couple of days; hence, any task longer than that has to be subdivided into smaller tasks. When scheduling task duration | effort, then: Set realistic workday durations per person, because not every project team member is going to be able to do a full 7 to 8+ hours worked per day on his or her assigned tasks. While they may do a full day’s work, there will be meetings to attend, workmates to assist, other competing projects requiring attention, administrative activities, and short notice leaves of absence (i.e. sick leave, single days annual leave). And, keep track of the individuals “resource utilization”, as assigning people 15 hour days is not conducive to their work-home –life-balance nor the viable success of the project. Hence, try the “Resource Levelling” tool on (a copy of) the 2nd Pass Schedule. Ensure that both Project Management (PM – Sn Mgmt.) and Technical Authorities (BA – SA – SME) are allocated time in the project’s schedule; i.e. appear as distinct tasks that are to be charged to the project’s Cost Account Code. When scheduling these ‘Project Management’ and ‘Technical Authority’ supporting tasks, then calculate these hours as a percentage (5-15% based on the project’s complexity / riskiness) of the Implementation total hours, and spread these over the project’s life. … And, these “support hours” are independent of any dedicated tasks in the project’s schedule that are assigned to specific ‘Project Management’ and ‘Technical Authority’ persons (such as for reviews, meetings, reporting); because, it is a certainty that these two parties will spend some unexpected time supporting the project’s activities. Ensure that all of the holiday breaks (including public holidays) are marked in the project’s schedule calendar; also, note when particular Project Team members would be unavailable due to their taking annual leave, or being assigned to other projects | Business As Usual activities, … and, their full-time or part-time work status. If certain features & functionality (or the order of implementation) won’t be clearly understood until closer to the time of the actual implementation (as per an agile based project), then allocate blocks of work effort hours (i.e. Sprints) during which these ‘To Be Defined’ tasks will be undertaken by the Project Implementation Team. Later on, during the execution of each Sprint the implementers will self-organize which tasks will be included in the particular sprint. See [Figure 31] reproduced below. Add contingency buffering to the ‘Critical Path’ (and to those feeder paths where there is reasonable likelihood of some delays occurring, such as with the delivery of hardware componentry); but, do not buffer every possible path through the project. Choose milestones (tasks assigned to zero days duration) that correspond to events of notable interest to the project’s primary stakeholders; e.g. the Start and/or the End of each major sequence of activities (such as the FAT, SAT, UAT testing), when funds need to be paid (such as international travel tickets), Progress Review meetings, progress payments for the work completed thus for, and the project’s Start Date & End Date. Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 46: The estimation of task duration is when size really does matter. Schedule Feasibility With the ‘draft’ 2nd Pass Schedule now completed, then talk it through with the senior implementers to determine whether they also consider the schedule to be a feasible plan, thereby, aiming to obtain “buy-in” from the representatives of the (potential) Project Implementation Team. “A project manager who does not consult with the implementers, and continually assigns task durations that are not feasible to successfully accomplish the given work, will soon lose the respect of the Project Team and will garner a reputation as someone who is … devoid of intelligence.” Having made feasibility adjustments to the 2nd Pass Schedule, then run this schedule past the Program Manager so as to ensure that no components have been left out (e.g. production of the mandated Objective Quality Evidence, Project Auditing, Progress Update Meetings & Reports, Post Completion Reviews …etc). That is, stuff that the implementers and the Project Manager) may have forgotten about. Also, ensure that the project’s sequence of activities & milestone dates are compatible with those other projects that are currently in the pipeline, and those projects that will be in the pipeline at the same time as this project’s implementation (i.e. on the program “roadmap”); thereby, aligning this project with the forthcoming Program Of Work. Additionally, there may be strategic business considerations such as; financial windows (e.g. the End Of Financial Year) where it is highly advantageous that the project has payment milestones that occur either prior to or after certain dates, that only certain amounts of money be spend in certain periods of time in which case only a certain range of Level Of Efforts hours can be exerted in that particular period (e.g. per quarter year), and progress payments (thus far) exceed the project’s costs incurred (to date). Once, it is understood how this project relates to other projects’ milestones, the availability of [People] & [Resources], and to other strategic business considerations, then the schedule should be adjusted accordingly. … And, an updated revision produced. Schedule Layout & Contents “Gee, I really have to zoom in here to examine the details. … … … … … WHAT!! You’re using MS-Project to calculate costs!! This is one situation where you should definitely use a spreadsheet, because a spreadsheet is better at the intricacies of the cost calculations; whereas, a schedule is better suited as a tool for tracking work versus time, the determination of the percentage complete, and the assignment of people & resources to tasks. In the spreadsheet, I would have a worksheet (or worksheets) for the major packages of work that were determined during the progressive elaboration of the Work Breakdown Structure (WBS) and the schedule. Once the worksheets have represented the project schedule, then I’d accumulate this cost information into a summation worksheet at the front of the spreadsheet to produce a total Contract Price.” Agreed, … however, this schedule is being used for the Initiating & Planning Phases estimation purposes; and, the inclusion of [Cost] in this example does demonstrate how the [People] & [Resources] assigned to tasks accumulate to drive the project’s [Cost]. Also, this schedule’s Costing is not the accurate calculation of the project’s Contract Price; rather, it provides an “in the ballpark” estimate of what the project is potentially going to cost, excluding Safety Margin (i.e. Cost Escalations, Cost Contingencies, and Risk Percentages), Management Reserve, and Profit Margin. For the scenario’s project, from the resultant schedule, the Level Of Effort is accumulated to 4940 hours, calendar duration of 10 months, and an Internal Total Costs of $910K which when adding a 25-50% mark-up (depending on the industry and the complexity / riskiness of the endeavour) for Safety Margin + Management Reserve + Profit Margin is a $1.14M to $1.37M Contract Price … initial guesstimation. “So, let’s see what a budget calculation spreadsheet comes up with.” As an aside, … how the project’s schedule is laid out is up to the schedule’s creator (i.e. the Project Manager), as influenced by how the performing organization’s senior management (including the Program Manager) expect to see project schedules presented. Though personally, I like to have at the beginning | top of the schedule; a clear identifier of the project’s name, then indent accordingly, a list of the Major Milestones (including any defined Start Date & End Date constraints), a list of the Progress Payment Milestones, a list of the Major Deliverables, a list of the (proof of) Progress Deliverables, then a rolled-up summation of the project’s tasking activities. This kind of schedule layout provides a sense of “visibility in control”, as the project’s primary stakeholders don’t have to go trawling through the entire schedule looking for information, because what is of major concern to them is detailed right there at the beginning of the schedule. … And, when the “Activity Execution” tasks are rolled-up to summarization form, then there is a nicely presented flow of Define – Design – Develop – Test – Deploy ( + Warranty Support), which goes a long way to satisfying the concerns of those “waterfaller” primary stakeholders. For the scenario’s project, the individual labor rates to be used (as per the performing organization’s standard rates) are: Hence, this project will require; 1x Project Manager, 1x Business Analyst | System Architect, 1x Lead Systems Engineer, 6x Software Engineers, 2x Testers, 1x Document Writer, and 1x Logistics Coordinator. “WOOH!! This portion of the schedule has individual tasking activities down to hourly resolution; this is way too detailed a breakdown for a planning schedule, as this could result in the micro-management of the project. And, just how detailed should you go for every group of tasks?” Agreed, … however, depending on what is stipulated by the performing organization’s senior management (including the Program Manager) and what the schedule is to be used for, then the schedule’s creator (i.e. the Project Manager) may be required to include such a detailed breakdown. In this case, to form the foundations by which to build an accurate calculation of the project’s costing. Also, recall that a project is deemed “a success” or “a failure” based entirely on the expectations and perspectives of the project’s primary stakeholders; hence, if “the bosses” require that the schedule contains such detailed breakdowns for certain activities, then so be it. Which brings us to the next rule of “Adaptive and Proactive” SDLC Project Management. RULE 47: It is best to give the project’s primary stakeholders what they want and need; rather than, quibbling over the level of detail. Schedule of Project Parts For this scenario’s project schedule, the Lead Systems Engineer will need to travel to the customer’s site to investigate how the to-be-delivered product should be integrated into the customer’s existing systems & infrastructure. As per the project’s contracted pre-arrangement, the customer is to be charged for travel time (to & from site), the cost of the travel method used, and for the project team member’s (away from home) accommodation & travel allowance expenses. Such costs of travel, accommodation, and expenses may or may not be included in the project’s schedule, depending on how the schedule is being used to determine; the sequence of activities to be conducted, the [Time] duration & Level Of Effort involved, the allocation of [People] & [Resources], and the preliminary [Cost] estimations. Though noting that, it is common for the Project Manager to be responsible for the project’s logistics of such things as; initiating the booking of travel – transport – accommodation, vendor & supplier relationships, procurement of software & hardware componentry, inventory controller, warehousing arranger, packaging obtainer, test facilities booker, import & export licenses organizer, … and, “last minute run around coordinator”. That is, the Project Manager’s role is as “Project Success Facilitator”, possibly functioning as a “jack of all trades” coverall goalkeeper for the project. Hence, if the inclusion of such tasks as “Travel to & from site Cost” and “Accommodation & Allowance Cost” are sufficient to remind the Project Manager (and senior Management) that these things need to be budgeted for and coordinated at specific times, then it is a good idea to add these to the schedule. … As it is those forgotten activities that can greatly affect the project’s chances of being successfully delivered on [Time] and within [Cost] budget. … “I forgot to budget for and book the airline tickets.” Also, in the the “Milestone – Closeout Report and Invoicing” (i.e. progress payment) for the work conducted up to this point. Whenever possible, strive to have progress payment milestones that result in a “positive cash flow” for the performing organization. Where, the accumulated amount of customer payments (REVENUE) up to that point would exceed the performing organization’s accumulated EXPENSE of conducting the project up to that same point. For this scenario’s project schedule , the Cost-To-Date for Part0 ($2700), plus Part1 ($46460), plus a proportion of Management & Technical Support ($12000) equals ($61160), which equates to 6.7% of the Internal Total Cost. Hence, set a progress payment of 10-15% of the Contract Price, negotiating for the higher percentage. “But, what about all of those hours of work that were involved with the project’s Initiating Phase to get the contract signed off?” Ideally, arrange for a ‘Time & Materials’ mini-contract for the project’s Initiating Phase up to contract sign-off, after which the ‘Fixed Price’ contract comes into effect. Though, the project’s Initiating Phase costs may be incorporated into the labor rates that are used for all projects, so that the costs of “LOST” projects is spread across those “WON” projects. For this scenario’s project schedule, the implementation is to be undertaken as three agile sprints of one month duration each, to be conducted by the Software Engineering Team of six team members; then, followed immediately by evaluation (feedback) testing by an “impartial” Test Team. That is, the Project Implementation Team are being allocated blocks of ‘Level Of Effort’ and ‘time duration’ during which they’re to complete the development & evaluation testing of the features & functionality that they self-organized the Define – Design – Develop – Test. Hence, in the scenario’s project, the agile Project Implementation Team is given a prioritized list of features & functionality that they are to deliver, i.e. a ‘Product Backlog’. At a time closer to the actual implementation, The Project Implementation Team then hold their own ‘Planning Meeting’ per sprint, with the Project Manager (and/or the BA – SA) acting as the ‘Product Owner’, where the Project Implementation Team select a limited number of features & functionality to be put into the ‘Sprint Backlog’, which they then self-coordinate the implementation. Thus, this is an example of how an agile based mini-project can be undertaken as part of a larger waterfall project. As an aside, in addition to the ‘Progress Summary’ updates being provided to the Customer’s Representative at the conclusion of each sprint, … for the Monitoring & Control Phase, the Project Manager would track the entire project’s progress via the use of Earned Value Performance Measures KPIs of CPI & SPI, whereas, the Project Implementation Team would track the progress of each sprint via the use of the Task Board & the Burndown Chart, For this scenario’s project schedule, the implementation part also contains procurement of the hardware componentry and the end-user software licenses, which will all eventually be turned over to the Customer. As per some project’s contractual agreements, the purchase of such componentry may be invoiced separately to the customer, or incorporated into the next progress payment. Notice the buffering tasks for the hardware delivery and systems integration. For this schedule, also note the inclusion of a ‘Dry Run Test’ a ‘Test Readiness Review’, and the sending off to the customer of the ‘Acceptance Test Procedures’. It is highly advantageous essential to conduct a private “dress rehearsal” | “dry run” step through of all of the test case procedures, prior to the customer’s involvement in the Acceptance Testing. Remembering that, perception is a significant contributor to the project being deemed “a success”; hence, “practice makes perfect”, and (more specifically) practice uncovers those obvious mistakes & silly defects that would degrade that customer’s perception of [Quality] deliverables. Additionally, by ‘Dry Run’ testing using the proposed ‘Acceptance Test Procedures’ that are to be sent to the Customer’s Representative for review & acceptance, then this will help to verify & validate those test procedures; as well as, how the Objective Quality Evidence (QQE) is to be recorded. … And, if during the ‘Dry Run’ testing a sufficient amount of OQE were to be produced (and if necessary) made available to the Customer’s Representatives for inspection prior to conducting the Acceptance Tests, then this could result in the Customer’s Representatives having a lot more confident attitude towards accepting the deliverables, … which, in turn could mean that the Customer’s Representatives are more forthcoming with signing –off on the progress payment milestones up to the point. For this scenario’s project schedule, the Cost for Part2 ($548300) alone, equates to 60.3% of the Internal Total Cost. However, Part2 spans a duration of 4 months which could be a noticeable amount of time for the performing organization to go without a progress payment; hence, the inclusion of a progress payment after each sprint’s evaluation testing. In circumstances where there is potentially a long time between the handover of customer deliverables as per the [Scope] of deliverables, then recommend injecting progress markers into the project’s schedule; where the Customer’s Representative may be invited to come witness demonstrations of the progress made thus far, or interim QQE could be provided as evidence of progress, or “preview” versions of the application | product could be given to the Customer’s Representatives for them to “play with”. … And so doing, attach “minor” progress payments to these markers; thereby, covering the performing organization’s costs of conducting the project’s implementation up to this point. For this scenario’s project, suggest that there be progress payments at the end of each sprint’s evaluation testing of (60% divided by 4 months equal) 15% of the Contract Price. Though, the customer may be hesitant on a 15% payout for sprints with no milestones deliverables, so be prepared to negotiate on a 12.5% payout for each, with 22.5% on completion of the FAT; given that by the end of Part3, 73% of the Internal Total Costs have been incurred. Try to keep a “positive cash flow” with respect to Progress Payments (to date) exceeding those Costs Incurred, try to “evenly space” these payments, and try to maintain similar sized payments. … Which can be “easier said than done” as the Customer’s Representative will most probably be negotiating to delay the majority of the payments until as late as possible; however, the customer must understand that, if the performing organization goes bust (potentially due to the financial difficulties resulting from such late payments), then the customer organization risks not receiving their commissioned deliverables. Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 48: “You must never try to make all the money that’s in a deal. Let the other fellow make some money too, because if you have a reputation for always making all the money, you won’t have many deals.” J Paul Getty For this scenario’s project, the Functional Acceptance Test will be conducted at the performing organization’s premises using their own in-house equipment (and possibly including the project’s procurements) that were used for the ‘Dry Run Test’; however, this time the tests will be conducted in front of the Customer’s Representatives. “Umm, think you’ve made a mistake in the schedule, as Task 205 should have the ‘Sw Lead Eng’ doing support and not the repeat of the ‘Sys Lead Eng’. … Just a $20/hr = $480 over costing.” Hence why the schedule should be reviewed prior to being used for further purposes; especially, prior to being presented to the Customer’s Representatives, as such mistakes (when discovered by the customer) can raise questions about the accuracy & validity of the rest of the schedule, and subsequently the correctness of the Contracted Price. … As stated previously, the purpose of the Functional Acceptance Test (FAT) is the reproducible verification that every in-scope feature & functionality described in the approved Detailed Specifications has been successfully implemented in accordance with the agreed Acceptance Criteria (as was prescribed in the reviewed & approved Acceptance Test Procedures). Subsequently, prior to conducting the FAT, it is advisable to hold a ‘Commencement Meeting’ with the Customer’s Representatives, so that the performing organization can layout before them, both the approved Detailed Specifications and the approved (FAT) Acceptance Test Procedures, … and, just in case any concerns arise, have the ‘Dry Run Test’ QQE ready to be presented as contrary evidence. In essence the Requirements Traceability Matrix (RTM) and the Testing Coverage Matrix (TCM) are the listings of the inputs and outputs to the Quality Assurance Processes and the Quality Control Procedures used to determine the “correctness” of the project deliverables that were agreed to. This “correctness” is subsequently determined via the undertaking of a sequence of acceptance tests, and the records of such testing forms the project’s Objective Quality Evidence (QQE). During the FAT, in the associated entries of the TCM, mark the PASS : FAIL of each test; thereby, identifying what features & functionality do & don’t operate in accordance with the agreed Acceptance Criteria. The TCM may also include references to any waivers if these were granted for specific failed tests; i.e. the test failed but this failure has been agreed to be acceptable under the current circumstances. The important thing is to keep the Customer’s Representatives focused on verifying that the project’s deliverables do comply with the functionality as defined in the approved Detailed Specifications; and NOT, their interpretation of its “fitness for use”. Because, potentially the FAT is the first opportunity that the Customer’s Representatives have to really use the deliverables; and, during such use they may realize that what was defined is not what they now want. Subsequently, they may incorrectly report certain features & functionality as Defects instead of Change Requests. At the finish of the FAT, a ‘Test Completion Review’ meeting should be held between the customer & performing organizations’ representatives to discuss & note any concerns with respect to the test results, and how the FAT was conducted. By the end of this meeting, the Project manager’s objective is to have the Customer’s Representatives sign-off on the completion of the FAT, as well as the resulting FAT Report (including QQE, deviations, waivers, and concessions), and then the sign-off on the associated milestone progress payment for the conclusion of the FAT. Conversely, the Performing Organization does not want this progress payment to be delayed due to differences of opinions over “what was specified” and “what is actually wanted”. Deviations, Waivers, Concessions, Defects and Change Requests During the Functional Acceptance Test (FAT), and the Satisfaction Acceptance Test (SAT), the following may be generated due to failed or incomplete tests: Deviation … written permission for a departure from the approved processes, procedures, and/or specifications used to produce or test a deliverable. Waiver … written permission for a non-conformance so that a deliverable may be accepted. Concession … a “special case” approval signed off by the representatives of the performing organization (e.g. the Project Manager and/or the Quality Authority); this concession grants the release to the customer of a deliverable (with or without repair) that is known to have specific non-conformances to the approved baseline. Such a concession is granted because, while the non-conformance is technically not a match with the approved baseline, the non-conformance is technically not a match with the approved baseline, e.g. increasing the storage capacity of the installed hard-disk due to market unavailability of the specified older model. Defect … where some feature or functionality of a deliverable does not conform to the agreed Acceptance Criteria (nor to the approved Detailed Specifications), and hence this defect needs to be rectified. Change Request … where some feature or functionality, as defined in the approved Detailed Specifications, will not result in the desired outcomes, or the agreed Acceptance Criteria is found to be inappropriate, subsequently the agreed [Scope], [Time] schedule, [Cost] budget, and/or [Quality] standards need to be changed. The reason that the above are listed here is because, during the project’s execution, dealing with these will consume some amount of the ‘Management Support’ and ‘Technical Authority Support’ activities that were included in the schedule. Just witness how much time can/will be consumed in activities involved with Baseline Changes, Defect Reviews, and Engineering Changes. For the scenario’s project, before the (site) Satisfaction Acceptance Test (SAT) can take place, all of the relevant procured & produced hardware & software have to be shipped to the customer’s site. Once onsite this hardware & software will have to be installed & integrated into the customer’s systems & infrastructure. These onsite activities will take time, a lot more time than can normally be expected; therefore “double it” the duration (nay “triple it”), because this is the customer’s facilities where things are done differently with various groups involved to get things achieved / rectified. Hence, buffer (“by any other name”); because, to fail with the in-situ installation & setup of the project’s deliverables can be rather problematic, costly, and a reputation damaging situation. Worse, is if the performing organization’s representatives who were sent to the customer’s site, if they have to leave to fix things up, then return later on to do the installation & setup properly; as “who exactly is going to pay for this do over work”, because it is possibly coming out of the performing organization’s own pocket. Thus, the importance that must be placed on those pre-SAT preparation activities, such as the creation of the system media (which contains the application software), preparing the hardware componentry, the packaging of such software & hardware, the shipping to the customer’s site of all of the required materials, followed by the onsite “professional” installation & setup of the in-situ project deliverables. Because, there could be serious ramifications for the performing organization if it goes wrong; hence, for a highly critical customer’s project, give serious consideration to conducting a local “dress rehearsal” | “dry run” setting up of the SAT (independent of the FAT facilities), so as to verify that everything is ready to go (including the tools that will be needed to do the job properly). Oh, how embarrassing and unprofessional it is to get to site and then realize that, you’ve forgotten the thingamabob.” DO NOT allow accountant types to “save a few bucks” on these pre-SAT activities, by cutting back on the quality of the products & services used, and the Level Of Effort involved; because, when onsite it will be regretted. “It is better to arrive early, over prepared, and have to wait; rather than taking it easy, under attired, and arrive later.” Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 49: Effective packaging, timely delivery, and efficient installation come to typify the performing organization’s quality image, and hence influences the customer’s perception of accept-ability & expect-ability of those project’s deliverables. COFFEE BREAK DISCUSSION … Away from home travel, don’t be an A.C.A. When planning & coordinating away (from home) travel for project team members, don’t think entirely from ‘A Cost Accountant’ perspective; remember that, the person who is being sent away (from home) for some period of time on company business, they also have a home life that will be affected by such travel plans. Question: How will their partner be burdened by having to handle their kids, alone? Will they miss their son’s or daughters, first spoken words, first steps taken, school play, dance recital, championship game, a life unfolding? What about their outside-of-work social & community commitments, who will take care of these things? What are they giving up, so as to go on this trip on the businesses behalf? Unfortunately, this is something that is often taken for granted when planning away (from home) travel for projects; because, the reality is that it is not just tasks and numbers in a schedule come spreadsheet, it is actual people’s lives that are affected. And, when continually taken for granted, this away (from home) travel can be sufficient aggravation catalyst for that inflicted project team member to ‘raise the middle finger’ and say, “I resign, I’m out of here, jerks”; leaving the project and the performing organization in an untimely predicament. However, with just a bit of courteous forethought, discussion, and arranging with the intended traveler, this away (from home) trip can be made a bit more palatable. How about, for an international flight, sending them business class so that they can actually get some quality sleep, instead of being showed back in economy class with no chance of real rest; yet expecting them to meet with the customer, all fresh. How about, sending them a day or two earlier so that they can have a day to rest, and partly get over that jet-lag; given that, they were sent economy class, thereby saving enough on business class to easily pay for those extra day’s accommodation. How about, instead of mandating that they must fly out early on Monday morning, they get to choose when they leave, so that they could have the weekend exploring the destination city, or leave on Sunday afternoon having said a proper goodbye to the family. … And, split the difference on the additional nights’ accommodation. How about, with an extended period away, that they have the option for their partner (and family) to come along, or to come visit for a few days. If they so choose; would the price difference between them voluntarily swapping business class for economy cover the cost of getting an extra seat for their partner’s travel? How about, for only a few dollars more, putting the up at “somewhere nice with civilized life” instead of being “stuck in a dog box with nothing to do”. How about, giving them a daily travel allowance (corresponding to the destination city’s cost of living), which enables them to “afford more than just bread & water”. How about, coordinating travel plans so that fellow staff (from difference projects & groups) stay together in the same place and intermix after hours. How about, when senior management are in town they drop-in to say “hi” and take the away (from home) staff member out to lunch or to dinner; instead of, ignoring their existence. Now, as a mere Project Manager, you possibly won’t have much say over the performing organization’s travel rules & arrangements; however, it would not hurt to put a case forward to senior management (on the project team members’ behalf). Sometimes “penny pinching” on travel, accommodation, and travel allowance can result in a more costly problem than those few dollars saved; as the affected project team member could very well decide to throw it all in and walk away, or their performance is sub-par because they are too tired or they just don’t want to be there anymore. For this scenario’s project, the Satisfaction Acceptance Test will be conducted onsite at the customer’s location using the customer’s provided equipment and the project’s procured equipment that was also shipped to site; and, these tests will be conducted in front of the Customer’s Representatives. As stated previously , the purpose of the Satisfaction Acceptance Test (SAT) is retest those features & function that were found to be non-conforming during the Functional Acceptance Test (FAT), and to verify that the provided / installed project deliverables are operating “satisfactorily” at the customer’s in-situ location. Thereby, the performing organization’s representative can (analogy wise) “hand over the keys”, confident in the knowledge that the customer can henceforth successfully “take it for a drive” to use the installed deliverables as has been configured. Thus, it is important to keep the Customer’s Representatives focused on verifying that the project’s deliverables are operating “satisfactory” in-situ onsite; as this, does NOT mean retesting every feature & functionality as was previously done during the FAT. However, there may be particular tests from the FAT that need to be repeated so as to verify that the deliverables are operating as expected onsite. Conversely, what the performing organization does not want to happen is for the Customer’s Representatives to be reinterpreting the deliverables “fitness for use”, and debating “how it should function”. Consequently, the SAT should be performed as prescribed in the approved Acceptance Test Procedures, so that if something does go wrong then it can be reproduced later on for rectification. Therefore, prior to conducting the SAT, it is advisable to hold a ‘Commencement Meeting’ with Customer’s Representatives, so that the performing organization can layout before them, both the approved Detailed Specifications and the approved (SAT) Acceptance Test Procedures, … and, just in case any concerns arise, have the signed off ‘FAT Report’ (and QQE) ready to be presented as contrary evidence. At the finish of the SAT, a ‘Test Completion Review’ meeting should be held between the customer & performing organizations’ representatives to discuss & note any concerns with respect to the test outcomes and to “hand over the keys” (if the SAT was successful). By the end of this meeting, the Project Manager’s objective is to have the Customer’s Representatives sign-off on the completion of the SAT. … And, once the performing organization’s onsite SAT personnel have finished (and returned from site), then the SAT Report (including QQE, deviations, waivers, and concessions) would be written up & reviewed prior to being sent to the Customer’s Representatives, then the sign-off on the progress payment for the conclusion of the SAT. … As always, try to keep the Progress Payments ahead of the Costs Incurred to date, e.g. 85% versus 82% respectively. “Umm, I think there are a few things missing from this schedule; primarily those defect repair activities that would occur at the conclusion of the FAT prior to the occurrence of the SAT, as these will definitely need to be added to the next revision of this project schedule. Oh, and I would also extend the Level of Effort and duration for the evaluation testing of each development sprint’s output. However, for now let’s continue on with reviewing this schedule as it is, and then you can update it later, before calculating the budget costing in a spreadsheet.” “ I knew I forgot something; glad it got picked up now, cause we’d definitely would have probably had to do that work.” Acceptance Testing … no such thing as enough testing It cannot be over emphasized, the importance of the ‘Evaluation’ testing that accompanies the development sprints, and the ‘Dry Run’ testing, as these are the most feasible & affordable opportunities to resolve any issues with non-conforming features & functionality. Similarly, effective & efficient “proper” (Factory) Functional Acceptance Testing (FAT) is the last truly affordable opportunity to make corrections of both Defect Repairs & Change Requests to the project’s deliverables; because, by such a late stage as the (Site) Satisfaction Acceptance Testing (SAT), and especially the (User) Usability Acceptance Testing (UAT), making changes & corrections can be a rather costly endeavor. Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 50: There is never enough testing prior to release. For this scenario’s project, the Usability Acceptance Test will be conducted sometime after the SAT, and prior to the Go Live. That is, after the defect repairs from the FAT and SAT have been incorporated into the deliverables that will be used for the UAT. As stated previously, the purpose of the Usability Acceptance Test (UAT) is to verify that the deliverables in-situ operation is as was commissioned (agreed to); hence, the deliverables are ready for end-user usage. While the UAT may occur immediately after the SAT, or some time afterwards; there is a major difference between the UAT and the SAT (and more specifically with the FAT) in that, while the SAT & FAT are well scripted activities with clearly defined Acceptance Test Procedures, the UAT is a more ad-hoc affair that is only bounded by the limitations specified in the Release Notes that accompany the project’s deliverables (as provided by the performing organization). Hence, for the UAT it is highly advisable that the customer organization provide end-users who are knowledgeable as to the purpose of the project’s deliverables, and who have some expertise in the field of endeavor where these deliverables are to be used. DO NOT underestimate the impact of the end-user, because without an appropriate level of work skills, experience, and training, then the end-user can misunderstand, misinterpret, and not know what the deliverables are and are not capable of doing. Consequently, the end-user could decree the deliverable to be “broken”, when in fact they are not using the deliverables as was duly defined (per the approved Detailed Specifications) and as was agreed to be acceptable (per the approved Acceptance Criteria). Conversely, being provided with end-users who have plenty of experience & expertise in the field of endeavor (i.e. persons who carry some level of operational respect within the customer organization) then this can greatly improve the perceived quality & acceptability of the project deliverables; because, these “expert users” can push the application / system beyond what the previous testers have been capable of achieving. … And potentially, due to the satisfaction of these expert users, they could directly & indirectly influence the Customer’s Representatives to sign-off on the deliverables, ASAP. {déjà vu} … At the finish of the UAT, a ‘Test Completion Review’ meeting should be held between the customer & performing organizations’ representatives (including available expert users) to discuss & note any concerns with respect to the test outcomes and to talk over the potential for the Go Live to commence as was scheduled. By the end of this meeting, the Project Manager’s objective is to have the Customer’s Representatives sign-off on the completion of the UAT. … And, once the performing organization’s onsite UAT personnel have finished (and returned from site), then the UAT Report (with a recommendation to proceed or not proceed with the Go Live) would be written up & reviewed prior to being sent to the Customer’s Representatives, then the sign-off on the associated progress payment for the conclusion of the UAT. … As always, try to keep the Progress Payments ahead of the Costs Incurred to date, e.g. 90% versus 87.5% respectively. NOTE: While the Project Manager may have diligently calculated the percentages for Progress Payments versus Costs Incurred to date; during the preceding contract’s negotiation between the Customer’s Representatives and the performing organization’s senior management, with the stroke of a pen, these percentages could be overwritten with greater values being placed on those final parts, and lesser values given to those implementation parts (where much of the internal costs are incurred). This senior management call, as they have to weigh up the cash flow implications versus the need to secure the contracted work. For this scenario’s project, the most critical part of the project is the Go Live occurring on a specific date. Where if this doesn’t happen then, well, … “let’s just make sure this does happen.” From the customer’s perspective, the Go Live is the most important & critical part of the project, as they could have a lot riding on the timely success of this milestone. Conversely, from the performing organization’s perspective, this part of the project marks the nearing of the end; to “screw-up” now could mean that much needed [People] & [Resources] are “bogged down” with completing this project, when it was planned (and is necessary) that they be available for assigning to other projects and to Business As Usual activities. With such a critical milestone as the rollout | switchover to a new or upgraded application | system, then ensure that there is some form of contingency plans in place, just in case the Go Live were to stumble or fail. Hence, there needs to be plan and procedures (documented & distributed to those who have to know) for switching back to the previous incumbent application | system, can the installation be uninstalled | rolled back, are there alternate working arrangements while the problems are resolved. OR, is it “a wing & a pray”, “she’ll be right mate” overoptimistic ado. “Hope for the best, but prepare for the worst.” Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 51: Failure to plan … adequately, is planning to fail … dramatically. For this scenario’s project, there is no incumbent application / system to switchover from, nor is there a rollback if it all goes wrong; there is just unplugging it from the infrastructure, … then the consequential impact on the customer’s other programs of work that depend on the customer’s other programs of work that depend on this timely Go Live; e.g. the public launch of the product, and the associated marketing & advertisement centered around that particular Go Live date. {dejua vu} … As with the FAT, SAT, and UAT, it is advisable mandatory to hold Commencement Meeting’ with both the customer & performing organizations’ representatives (as well as any directly involved 3rd parties), prior to commencing the Go Live activities. Effectively this Commencement Meeting is the kick-off meeting to the proceeding Go Live activities where the persons involved need to be explained the “Go Live Plan’, the timings, and who is responsible for what & when. This Go Live Plan was possibly prepared by the Customer’s Representatives with input from the performing organization’s Technical Authority & Management support, as well as any involved 3rd parties, and the distributed prior to this meeting. And so, the Go Live activities should occur in accordance with the Go Live Plan. {deju vu} … At the finish | halting of the Go Live, a ‘Completion Review’ meeting will be held between the customer & performing organizations’ representatives (including directly involved 3rd parties) to discuss & note any concerns with respect to the Go Live outcomes, and if things didn’t go as was planned then to initiate alternative arrangements. By the end of this meeting, the Project Manager’s objective is to have the Customer’s Representatives sign-off on the completion of the Go Live. … And, once the performing organization onsite Go Live personnel have finished (and returned from site), then the Go Live Report would be written up & reviewed prior to being sent to the Customer’s Representatives, and then the sign-off on the associated progress payment for the conclusion of the Go Live. For this scenario’s project, once the Go Live occurs then the Warranty Support commences as per the Terms & Conditions of the contracted agreement. “Umm, might be a little bit too high with those technical support hours, how about halving those.” While being at the end of the project’s life, this ‘Warranty Support is when the performing organization can inadvertently get itself into a bit of trouble (without some pre-thought, or by being “stingy” with spending project money) on these activities. For example, due to: Not retaining / assigning (either full-time or part-time) members of the Project Implementation Team to the project’s Warranty Support activities. Hence, when a valid warranty claim is lodged by the customer then the performing organization has to “scurry about” finding personnel to deal with the claim; while, disrupting other projects and Business As Usual activities in the process of hurriedly rearranging & reassigning personnel, or having to default on the timely servicing of the claim. If there are activities that need to be done to make the Warranty Support viable (when a warranty claim is made), then proactively do these activities before the performing organization gets caught out by not being prepared, and has to react hastily due to their inability to immediately honor such warranty claims. While the contracted terms stipulate that the Go Live sign-off marks the commencement of the Warranty Support period; however, some of the project deliverables incorporate 3rd party items whose own warranties commenced when these items were received by the performing organization. Thus, what if there is a gap of time between when the performing organization originally received the item and when the item is handed over to the customer as part of a deliverable; potentially, a portion of this time gap may no longer be covered by the manufacturers / vendors / suppliers warrantee, and subsequently such warrantee has to be covered out of the performing organization’s own pocket. Therefore, it additional periods of 3rd party warranty can be purchased then it is prudent to purchase such an extension. This is more of a Senior Management issue to resolve than the Project Manager) … The customer’s imposed contracted terms are such that, once the deliverables are installed into the “pilot” site and the Go Live is completed, the official Warranty Support does not commence then (and nor are the final payments made); rather, the Warranty Support is to commence at the conclusion of the proceeding “Field Test Evaluations’. … Unfortunately, this “eval-u-a-ting” seems to drag on almost indefinitely; as though, being treated by the customer as an extended “free trial”. To prevent the project from dragging on, there needs to be a clear definition of when Warranty Support ends and when (an independent to the project) ongoing maintenance & support contract commences; as the servicing of Defect Repairs & Change Requests project, and subsequently a drain on resource availability & a financial burden on the performing organization. For this scenario’s project, once the Warranty Support concludes (as per the Terms & Conditions of the contracted agreement), then the project can finally be closed out. Project Closure, as detailed before, is when it is ensured that “everyone agrees, it is all done”. “Umm, think you might want to double the durations for those closure activities from a day each to a couple days per person, as there is always some fiddly bits to tie off at the end.” During the project activities, it would be beneficial to hold an internal project closure review to identify (and possible fix) any unresolved issues. And, once the performing organization’s project closure activities are completed, then write up & review the Project Close Out Report prior to sending this off to the Customer’s Representatives, and then the sign-off on the associated progress payment for the conclusion of the project. … The allocation of additional hours would be used for unplanned activities that are highly likely to occur, due to: Such activities as the Customer’s Representatives could require some amount of managerial and/or technical request servicing (aka “handholding”). The project is “leading edge” where a noticeable amount of management & technical authority support will be consumed dealing with the management & support of the risks associated with such a development; in such a case a 25-33% addition may be necessary to cover the time involved with resolving the known-unknowns of such a project, similarly a “bleeding edge” technology project may need an even higher ratio. The important thing to remember, is that no matter how detailed the planned schedule (to the point of micro-managing) there will always be managerial and technical issues that will have to be handled in addition to those activities planned for in advance. … Update the Reviewed Schedule Having concluded the internal review of the (proposed) project’s schedule with senior management’s (i.e. the Program Manager), then update the next revision of this schedule with all of the noted additions & adjustments. Then, follow up with another quick run through to verify that the revised project schedule is viable; before delving into the detailed calculation of the project’s [Cost] budget. For this scenario’s project, having reworked the schedule including all of the review notes, it is found that the schedule has pushed into the Go Live date. … And, if the personnel sent to site were to return between the UAT and the GO Live activities, then it would not be possible for the Go Live to occur on the stipulated date; hence, the proposal is for the UAT to be used as the lead into the Go Live, with the personnel only returning after the Go Live finishes, with remote technical support back at the performing organization to resolve any last minute issues. For the scenario’s project, the Level of Effort is accumulated to 5091 hours (up from 4940 hours), calendar duration is still 10 months, and the Internal Total Cost of $1,026K (up from $910K) … which is about a $1.28M to $1.54M Contract Price (up from the $1.1.4M to $1.37M initially guesstimated) which is a 12% increase. Which brings us to an addendum to “Adaptive & Proactive” SDLC Project Management. RULE 51A: Failing to catch those missing tasks and misplaced dependences can have a dramatic effect on the dates, and the Level of Effort involved … And, on the calculated budget. NOTE: When viewing the revised schedule on the following pages, there are probably a few changes, additions, subtractions, and rearrangements that you could suggest; hence why, the schedule should be reviewed by various persons in the performing organization prior to being presented in whatever form (summation or detailed) to senior management, … and, eventually to the Customer’s Representatives. “As an implementer, did you ever stop and think what your day’s work and your employer; and, what a day of your project team’s time also costs?” Well, in the scenario’s project case, each development sprint has an internal cost of $132,000 plus $15,890 for each evaluation test, plus system integration $99,910, plus dry run testing $61,330, plus review $6,025, plus management, equals a total of $612,415 in four months. … “Or, a rather decent mortgage repayment on a nice house”. “Gee how the hours and dollars keep adding up; … that block of tasks there is the cost of a brand new family car, … that chunk could pay for the renovation of the bathrooms & kitchen, … there’s a holiday trip.” Yes, that is a fair amount of money (capital) that both the customer & performing organizations will be investing in the conduct of this proposed project. … So will it really provide a worthwhile Return On Investment for both of these organizations? Integrating the Project Schedule Into The Program Roadmap With the revised schedule having been re-reviewed, then the Project Manager will proceed with producing the [Cost] calculation spreadsheet; while the Program Manager takes a copy of that schedule and works this as a timeline representation of a summation schedule into the Integrated Master Schedule (IMS) | Master Program Schedule (MPS) | Program Roadmap, … or, various other names used depending on the organizational and industry. The Program Manager will use information extracted from this (proposed) project’s schedule to determine: How does the project’s flow of overarching work activities (with major milestones marked out) compare to the performing organization’s other (proposed & actual) projects that are also included in the “roadmap”? Are there multiple projects vying for (almost simultaneous) access to limited resources such as; scarce equipment (e.g. the thingomajig analyser), restrained work-stream facilities (e.g. testing labs), specialist work groups (e.g. circuit layout), and individuals (e.g. chief mathematician)? Are there multiple projects whose combined (estimated) cash outflows for a given period (monthly | quarterly) would exceed the performing organization’s potential to cover such a financial burden? When are the expected cash inflows to occur? What is the resource loading people loading across the various projects, are there shortfalls in availability (where additional personnel would need to be engaged), and there times when better arranging could result in optimal utilization? Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 52: No project is an island, entirely isolated to itself. … A project is one of many in a stream of past, present and future; where each affects each other’s chances of success. The Project’s Schedule Accumulated Level Of Effort as a S-Curve Having revised the project’s schedule, if the Level of Effort for the “Management Support” and the “Technical Authority Support” activities were spread evenly across the entire duration of the project, and then the weekly totals for the Level Of Effort for all of the project’s activities were accumulated then the S-Curve Now, this “internal costs incurred” S-Curve [Cost Baseline] is yet to include the Safety Margin, Management Reserve, and Profit Margin as these also need to be included so as to determine a “viable” Contracted Price. But these additions, in difference to the side diagram, probably won’t be included as clearly defined drop-ins on top; rather, these will be incorporated into the “Sell Price” of the Labor Rates and Material Prices charged. Hence, there is a need for a dedicated calculation spreadsheet (aka “Cost Account Authorization”) to produce an overall budget Contract Price. 6.3.4. What Will It Cost? Simplified Cost Formula There is an old saying that, “time is money”, and, “you break it, you buy it”, which from a project [Resources] perspective is “you used it, you pay for what you used”; essentially, a “Pay As You Go” philosophy, where: Costs = (People Labour Rates * Time Used) + (Resource Unit Prices * Amount Used) + (Fixed Operating Costs To Date) But, what to use for the marked-up “Sell Price” for the [People] Labor Rates and the [Resource] Unit Prices, and those Fixed Operating Costs, when there needs to be included Escalated Costs (exchange rates & inflation), Cost Contingencies (warranty repairs & latent defects), Risk Contingencies (type of work being conducted), Overhead Burden, Management Reserve, and Profit Margin … which all have to be incorporated into the [Cost] calculation. People Labour Rates = Base Labour Rates * 1.?? 1.?? = Percentage for Escalated Costs + Percentage for Cost Contingencies + Percentage for Risk Contingencies + Percentage for Overhead Burden + Percentage for Management Reserve + Percentage for Profit Margin The [People] Labor Rates will be different depending on the type of work conducted, where some relatively simple activities have a small Risk Contingency, whereas other activities (such as R&D) have a much greater Risk Contingency. Hence, in the cost calculation spreadsheet, different [People] will be assigned different categories of work. DO NOT allow these Sell Price percentage combinations for Escalated Costs, Cost Contingencies, Risk Contingencies, Overhead Burden, Management Reserve, and Profit Margin to be known by the Customer’s Representative (or competitors); because, to have this information revealed will greatly damage the performing organization’s capability to “profitably” negotiate with the customer. … And, to enable the undercutting by competitors. “So, don’t accidently go emailing the costing spreadsheet to the customer instead of a separately prepared quotation. … DOPE!!” Similarly for [Resources], there would be different Sale Price markups based on the type of materials & services that will be provided. For example; travel, accommodation, server hardware, software licenses, packaging & freight. Contract Price – Overall Budget Calculation Hence, using the performing organization’s “standardized” Cost Account Authorization spreadsheet, start constructing the budget; What is ‘Ohead’ Overhead in the Burdens & Margins? This is to cover the overhead cost of printers & servers, I.T. infrastructure, I.T. support staff, office administration, executive management, staff training, recruitment, operating permits, … etc. With the revised schedule, for each of the major parts of the project (e.g. Part 0 – Project Kick Off, Part 1 – Analysis & Design, Part 2 – Implementation, … … Part 8 – Project Closure) accumulate the hours | Level Of Effort per [People] working on that particular part. Then, in the Cost Account Authorization spreadsheet, in a worksheet for the Work Breakdown Structure enter the work to be done by each of the involved performing organization’s [People], and the [Resources] to be utilized. … As, the spreadsheet automatically calculates the Sell Price percentage combination markups per entered item; thereby, determining the project’s accumulated Contract Price (to be offered). Thus, for the scenario’s project the Internal Costs versus the Sell Price are as follows: Hence, for the scenario’s project the performing organization’s senior management would provide the customer’s a representatives with a $2,055M Offered Price. Contract Price – Negotiations During the contract negotiations between the performing & customer organizations, there may be some concerns raised that the offered Contract Price is “way too high”. With no reduction in the agreed [Scope] of the project, then … instead of slashing the Level Of Effort hours [Time], … the performing organization could consider the following options: Reducing the Base Labor Rates per [People] involved with the project; noting that, this base rate would include some “fat” to cover the cost of the project’s Initiating Phase work which occurred prior to the contract’s sign off, and to cover the costs involved with those proposed projects that were not won. … “Also, $200 per hour for a permanent salaried worker at 40 hours/week X 52 weeks / year = $416,000 per annum; but rest assured that, most probably, not one of the project team members are on a salary of half that rate. Similarly, a junior software engineer at $110 per hour, definitely ain’t getting a yearly salary of $229k; though, they would probably be satisfied with a third of that”. For example; a 25% “discount” on Labor Rates would result in an Internal Cost of $1,173,788 (vs. $1,321,313) and a Contract Sell Price of $1,819562 (vs. $2,054,569). … Still not good enough, then how about a 50% discount” for an Internal Cost of $1,026,236 (vs. $321,313) and a Contract Sell Price of $1,584,554 (vs. $2,054,569). Reducing the Burdens & Margins (i.e. the “magic number” percentages) for Cost Contingencies (warranty repairs & latent defects), Risk Contingencies (type of work conducted), Overhead Burden, Management Reserve, and Profit Margin. For example; if the Profit Margin was reduced from 12.5% to 5% (without any other changes) then this would result in the Internal Cost remaining the same ($1,321,313), but a Contract Sell Price of $1,924,080 (vs. $2,054,569). Thus, what downwards adjustments could be achieved by tweaking others of those combination percentages? ONLY A FOOL reduces the Contract Price by reducing the Level of Effort without a corresponding reduction in the Scope Of Deliverables. Please refer to for “pricing the project to a certain death”; because, one of the battles that the Project Manager will face, is when Sales & Business Development (and even senior management) reduces the project’s Contracted Price by cutting back on the Level of Effort without reducing the Scope of Deliverables; as this puts the “actual burden” for the project’s profitability onto the members of the Project Implementation Team, … as unrecorded overtime hours that these [People] will have to work, if this project is to have any chance of being completed on [Time] schedule within the stipulated [Cost] budget, … which can result in these [People] being unable to focus on producing “satisfactory” [Quality] [Scope] of deliverables. Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management. RULE 53: Level Of Effort is to [Scope], … as [Time] is to [Cost]. COFFEE BREAK DISCUSSION … Like to take a razor to that goat. It really gets on my goat, when you spend a lot of time & effort preparing a realistic project schedule and diligently working out a viable project budget; then some fool in Sales & Business Development (or even senior management), who has zero (or no recent) experience with actual hands-on system development, they come through and willy-nilly slice chunks of hours off the durations for tasks without having the faintest idea as to the complexity of what is actually involved with those implementation tasks. “Do you realize that we’ve complained about this problem twice before in coffee break discussions. … Maybe we need some counseling.” “Yah, lay back on the couch, and tell me, all about it”.