12

Firstly, you should be clear on the terms you are using. An estimate, which should be a range of results, is different than a target, which is a single number to which you are marching and which lies somewhere in the range of your estimate. So you are talking about targets. The rule is easy: you break down your work to the smallest level that you need to ...


10

You can have a technical leader. You can have him do work off the charts. You can hide this work from others that don't "need to know". You can reduce that person's capacity to make planning more accurate. But you cannot call that Scrum. One of the key features of agile (and, by extension, Scrum) is transparency. Transparency: This means presenting the ...


10

TL;DR If the work matters, make it visible. If it doesn't, then treat it as muda and trim it as non-essential waste. You truly cannot have it both ways. No Invisible Work, Ever!™️ CodeGnome's Law of Transparency says "No invisible work, ever!" Any work that is off the books violates that law, as well as generally-accepted agile principles and practices. ...


8

The WBS breaks down what you are building for the project into smaller, more manageable components. In most cases, the WBS should be things, not actions. The leaf level, the lowest decoposition of the WBS, is your work package. The work package, and the activities and resources--both human and materiel--are scheduled for deployment. You can include the ...


8

More communication? Yes! Always. Especially if you can't come up with any reason not to. The worst thing that could happen is that you actually find problems and have to fix them. As far as estimates, be careful. Don't let non-technical people try to bargain with estimates. (Hopefully)Those estimates were created by the technical people who will be ...


8

Promote "Promotional Pictures" to a higher level WBS element. So when you break Street and Social down, the promotional pictures does not become part of it.


7

Sounds like your schedule could benefit by including dependencies.Promotional Pictures is not a "sub-task" of the two campaigns. It is a predecessor task for whatever step comes after completing the promotional pictures task.


7

What you are trying to visualise is a network plan, not a WBS. A WBS does not show dependencies, only the scope or deliverables and subdeliverables that needs to be realised in order to succesfully complete the project. A network plan places all WBS-elements in their logical sequence in order to show the growing maturity of the project deliverable. So ...


7

If you assume an employee puts in 8h days, this rule would mean that a task takes no longer than two man-weeks and no less than one man-day. This ensures that the task is large enough to be meaningful, but not so long as to have no visibility into what is happening. In other words, a task that takes 4h may not be worth doing--it could be wrapped up with ...


5

Ideal Hours vs. Everything Else Your work breakdown seems to be based on ideal hours. While there are proponents of this approach, ideal hours rarely track with any precision since estimates are usually a distribution. Another person said: [P]recision doesn’t equal accuracy and accuracy is what we’re really after. In other words, whether any given task ...


5

The real questions are should you ask, what should you ask, and how you should ask. I totally agree with Jody, but here are some things I've picked up in regards to involving the client in project planning: I almost lost a client because I was too technical and he thought that meant the final product would be too technical. I went 2 months over a deadline ...


5

It looks detailed enough to me if it is in days. If it is in hours, then it is too detailed. A half an hour work rarely takes half an hour. Usually, it is more. There is an "Exception Handling" task, which may not be a good idea to do separately. Additionally, in comparison to the other tasks the time you'll spend on it is technically zero. Here is a ...


5

TL;DR Communication plans or communication activities should only be included in a work breakdown structure if they are the deliverables. Even in such cases, the breakdown should reflect steps in the project rather than daily calendar items of interest only to the task performer. Define Your Level of Granularity Your question is not directly answerable ...


5

There are two types of communications, in my view. One as a consequence of doing work, the other as specific outputs or deliverables. For the former, I would not exhibit it in the WBS because it does not buy you anything from a measurable point of view. I would consider this type of communication--risks, meetings, troubleshooting, design discussions--in ...


4

In Effective Work Breakdown Structures, Haugan has "Project Management Elements" as a toplevel WBS item and moves all such work under that element. A lot of people don't consider process documentation to be an output of a project -- but it is. Such documents form inputs to other projects and to analysis. They're clearly a tangible output, and so belong in a ...


4

No, the WBS is not outdated, obsolete, deprecated, nor useless. The WBS is just a decomposition of WHAT you want to deliver. Building a WBS is not a one-shot task, but it is an interactive and iterative process. One best practice in project management is to create a product oriented WBS, that you will use later to structure your planning. In my article "...


3

Yes. The WBS should include all the work needed to successfully complete the project. The 100% rule states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management. The 100% rule is one of the most important ...


3

Remember the 100% rule. If the pictures are shared between media, then listing them under two headings breaks the rule by double-counting. In some WBS schemes you always put "cross cutting" concerns in their own hierarchy. So some WBSes have items for Work X, Work Y and then a heading for "Project Management Work" to track that in one hierarchy, instead of ...


3

The WBS is a time independent decomposition of the work requires to compete a project. After you assign owners and sequence the tasks, one output is the Gantt chart. The Gamnt is uaully at a much higher level.


3

Given the multiple dependencies, 'promotional pictures' would a separate deliverable, and the as the others said, a predecessor to the other deliverables (campaigns).


3

It sounds like you might be describing the differences between a Product Backlog and a Sprint Backlog and perhaps a Release Backlog in the middle. Product Backlog- Everything desired in the product. This can be a finite list (a PRD) or a living list that is constantly being added to and re-prioritized. Release Backlog- This is not in the base scrum ...


3

There is nothing in the agile approach that specifies the size of requirements. Scrum, which is an agile framework, does specify that the amount of work planned for a sprint should be completable within the sprint. That would imply a maximum size of a requirement such that it does not exceed a sprint (typically 1-4 weeks). In practice though, there has been ...


3

The 8-80 rule was created to help 24/7 health care facilities avoid overtime pay because of scheduling difficulties related to union labor contracts giving the regular staff at least every other weekend off. Because of the weekend off requirements, it was mathematically impossible to adhere to the previous 8-40 rule without a mish mash of overtime payment ...


2

More information is needed to determine if granularity is about right. I'll suggest some criteria that can be applied: Are there any external dependencies internal to any of the tasks? If so, obviously, the task needs to be split to allow the dependency to be tracked. Is there significant adverse risk associated with any of the tasks? If so, can the task ...


2

As Bartosz writes in the comments, there can be multiple levels between the top and the lowest level of your WBS, and the number of levels of each sub-tree depends upon the deliverable itself. Now, the first level often depends upon how you wish to structure your WBS: it could be by project phase (if each phase has distinct deliverables) or by product. We ...


2

Some suggestions: Hammock Control Account Parent Deliverable / Activity Sub-project Group of deliverables


2

I haven't used any of them for PM recruitment but there are a lot of 'collaborative consumption' sites out there where you can post an opportunity and get bids in for the work from suppliers (Elance is one of the most popular). You'll more than likely get bids from individuals or small companies rather than large consultancies. Stepping back a little I'm ...


2

Typically I've used a product description for each deliverable that goes along with the WBS. That product description would include dependencies so that you can spell out what inputs deliverable X has and what other deliverables X is required for. These can also help capture acceptance criteria, underlying assumptions, owners, budgets, etc etc and are ...


2

Given that some communication activities will create dependencies and extend the overall project schedule I think it's essential that the communication overhead is taken into account in the WBS. However, for the most part I wouldn't say that all of it needs to be explicitly included. One of your example activities is the meeting to discuss project risks. If ...


2

I agree with @Daniel's comment that this is a poor question to ask. In terms of suggestions be wary that this may be in part a trick question as a mistake may be components missing from the WBS. For example, a best practice is to include project management activities (initiating, planning, controlling/monitoring, closing) in the WBS as they represent work ...


Only top voted, non community-wiki answers of a minimum length are eligible