1

I wonder if activities like contract and agreement reviews, meetings to discuss preliminary information, SOW review, and contract approved (as deliverable and milestone) should be included in a gantt chart in a specific task list/group to be presented to an external customer or we should start our planning after our contract has been approved and skip this detail in the gantt chart.

I think that there are many different styles, contexts, and scenarios. I would like to know the general rule for these activities.

Once you define your baseline, will you include the reviews to ammend the contract, tracking all the meetings with the client?

In case you include all these activities, your start date for your project should be after contract approval, but gantt would make reference to date that we submitted our proposal.

Improve this question

4 Answers 4

Reset to default
3

The work you do before you have contract is of no concern to the customer. The customer would not care what you did, how much it cost you, whether you had issues doing that work, etc. If you added it to the customer's scope of work, it's only noise that adds no value. The other way to look at it is that it is none of their business, either. You may have your own schedule, and a way to capture your costs, for work performed during the capture phase through proposal and through signing. And some of that work may inform your project work, i.e., early planning stuff, but it does not belong in the project's artifacts.

Improve this answer
1
  • Thanks for your answer. I will avoid to include activities before contract. Nevertheless, according to Mark's answer. Once contract + SOW have been approved, WBS should be built from where I would get my activity list. Do you include Proj Management deliverables within the WBS?
    – Maximus Decimus
    Commented Apr 25, 2019 at 20:26
2

For the customer proposal, no. But for internal use, yes. The effort spent on such things is important in that it consumes time for those doing the tasks so it’s ilportsnt for the organization to understand work loads.

Improve this answer
1
  • 1
    Interesting the idea of considering the two aspects of this - internally and externally. +1!
    – Tiago Cardoso
    Commented Apr 14, 2019 at 13:14
1

PMI's process assumes that the schedule plan is developed during the planning phase. The other activities you describe are relevant to the initiation phase.

Personally I wouldn't build a Gantt till I'd completed the WBS, and I wouldn't do the WBS until I had an approved project charter.

Improve this answer
1
  • Thanks for your answer. It makes sense what you say. I agree that I wouldn't start a WBS with no formal approval of the PC or SOW. A WBS is based on deliverables and WorkPackages basically, but once I've been told that a leg from the WBS should be reserved for Project Management (PM). Deliverables for PM like planning, risk plan, stakeholder doc, etc. should be included there in the planning/gantt. As I see it, WBS to me is product-oriented more than only activities.Do you include PM into your WBS?
    – Maximus Decimus
    Commented Apr 25, 2019 at 20:16
0

My though is that if something impacts the schedule, you should track it.

We have to submit change orders (CO) with milestone dates -- the problem is approval for the CO can vary drastically (from days to months) and you never know what it will be. Therefore we include tasks like the following (All dependent on their predecessor):

  1. Jan-1 "Submit CO [1-Day]" (Assigned to me)
  2. Jan-2 "Approve CO [30-days]" (Assigned to Client)
  3. Feb-1 "Do real work part 1 [x-days]". (Assigned to me)
  4. Mar-1 "Do real work part 2 [x-days]". (Assigned to me)
  5. April "End User Approval [x-days]" (Assigned to client)
  6. May-1 Milestone: "Project Complete"

In this example, we show work that occurs before the contract is approved because we want to show real work cannot start until the client gets approval.

If the approval takes longer than 30-days, that pushes out the other deliverables. If the client misses their responsibility (Approve CO) that affects the rest of the agreed on schedule and requires a change management process address the schedule change. The change management process addresses changes in scope/money/schedule and is a negotiation between you and the client.

The change management process is an important step because you may have agreed to finishing up by May-1 because in June you have another project starting or maybe your developer is going on vacation. If approval ends up taking an extra 15-days (45D vs 30D), it could push your final deliverable out 60-days (Because the developer is taking time off in May). By adding the "Approval" step, you make it clear to the client that the date is important.

NOTE: You can also cover this under the risks/assumptions section of a project plan instead of the project schedule.

SIDE NOTE for complex CO/SOW: Most times, creating a CO/SOW only requires a meeting or two and we swallow that cost. But, if preparation for the CO/SOW is long, you may need to treat creating the CO/SOW as a separate project with a deliverable of the CO/SOW for the second project (actually doing the work). Sometimes creating the CO/SOW requires a bunch of work from our BA/Architect; that is when we do a CO/SOW to create the final CH/SOW. Due to budgets, we have done a $50k project to create a CO/SOW and then waited a year before executing that CO/SOW.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.