8
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 ...
6
The simple answer to "What does the PM do when the milestone passes" is:
Re-schedule the project plan to take the delays into account then report on milestone changes back to the project sponsors and stakeholders.
It is assumed that the PM would have been raising a risk to the project schedule in the risk log and talking to all relevant people in the run ...
5
here are few suggestions:
Prepare some statistics for your team for the next retro, better visual. You had 6 iterations already, so I assume you have data to show. It should help to convince them.
Suggest to take smaller amount of stories for the sprint (e.g. your historical 13 stories), but if they have time - they can take stories from the backlog.
Simply ...
5
There are a few issues in sequencing: 1. if I sequence the tasks with just the predecessors, the Gantt chart will be very hard to read--it's hard to read already as we have so many tasks
Task links should be based on the reality of the work. Don't be concerned about how the Gantt Chart looks. If there are too many link lines showing, modify the chart to ...
5
This scenario feels Waterfall because of the fixed scope of 8 epics and fixed schedule of 10/21/2021 so I wouldn’t say your feeling is off on that point. However, this is very much reality in many contexts therefore I can see some utility in this as an exercise in laying out a strategy or approach.
With that said, you may start with working backwards from ...
5
This is a weird test.
You have a fixed time, fixed goal and fixed resources. Nothing there is flexible. There is no decisions to be made here. You are not a project manager, you are a project statistician.
You can make the boards and graphs showing progress, but in the end, it's like a movie. It will play. It will either have a happy end or not. But none of ...
4
The dependencies between tasks are based on logic and choice. Logic are hard dependencies and are created because one task cannot start until the other has finished--assuming a finish-start relationship--under any circumstances. For example, you cannot paint a wall until you hang the dry wall, which you cannot do until the wall is framed. You have no ...
4
Use a driving milestone.
Start the schedule on an arbitrary date - the date when the river is most likely to have minimum flow. Then include a milestone "Low flow achieved" on the same date. Subsequent tasks depend on this milestone. If the river is at low flow, then the milestone is met and the next task starts. If the river is still high, then that ...
4
I think that your second image is a template that you should use to plan out your Sprints. Where did you get the image?
You do a longer release planning with Scrum by:
organizing your backlog with proper priorities for the items;
do a rough estimate of the backlog items;
then using your team velocity and known duration of a sprint, try to figure out how ...
3
Many project managers can handle multiple projects, so by implication, they are working a reduced schedule on each project. It is therefore both practical and effective to do this. But there are areas that need careful handling.
Ensure the role is clearly defined. Manage the project, but don't get dragged into the fine detail. Concentrate on the things that ...
3
I am going to answer this question in a completely different way. My answer will not technically answer your question but may provide you with another alternative in building your schedule.
First, I prefer to keep all / most of my work packages as fixed duration since in most cases we as PMs have to communicate a firm delivery date. So managing to ...
3
The Scrum guide talks about a forecast instead of commitment. (They changed this from commitment in 2013.)
However, enough work is planned during Sprint Planning for the
Development Team to forecast what it believes it can do in the
upcoming Sprint.
It is not so bad to not complete your teams full forecast. What is important is that the highest ...
3
Predecessor-successor logic in a project is based on the fact that most tasks flow in a logical order, either because work demands it--you cannot hang drywall until you have finished building the frame--you have resource constraints--you have only one front loader so task A needs to finish before you can move the resource to do task B--or you simply choose ...
3
To what extent can a Project Manager be held responsible for projects remaining on schedule and on budget?
Junior PMs are assigned to projects with low complexity for a reason. If you were to assign me, an IT project manager, to build a new space station, it will fail. Someone can try holding me accountable for that, but you should have never assigned me to ...
3
If you ask if Kanban is going to help you deliver, it won't. Actually, none of the methods will.
There is the project management triangle. If the time which says that you cannot have all the angles - scope, schedule, and cost - fixed. If your scope and schedule are fixed, the only thing is left for you is to hire more people that increases cost, increases ...
3
You cannot do this without picking an arbitrary date. All tasks and milestones in MS-Project have start and end dates.
I would introduce one level of abstraction though- I would add a milestone with a title of "Ready to commence construction" and give it a "Start no earlier than" constraint. Then pick your date sufficiently far in the future and at least ...
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 ...
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 ...
3
Yes we can, planning in Scrum is done at three different levels: daily planning, iteration planning; release planning.
From team's point of view, the release planning gives us the direction, the iteration planning gives the structure and the daily planning gives the context for the next days.
All the planning allows risks to be identified early and so we'...
3
What you're trying to do makes no sense.
The first problem is that story points have no relation to time. Story points are a measure of effort needed or complexity. Something that requires a lot of effort may be something that can also be done very quickly. However, something that is estimated to be a very small amount of effort may be done with the same ...
3
Dummy activities may be needed to correctly represent the depndencies between activities
In the following figure, why do we need a dummy activity? Why can't we
just connect directly instead of putting a dummy activity?
To answer your question, we will try to draw the diagram without any dummy activity.
This one is wrong because C need not wait for D.
...
2
Assuming that the example you gave was merely illustrative and that you are interested in the more general question:
The interesting thing about this question is that it reveals how many things can be assumed inside task dependencies. Dependency should be a matter of demonstration, not decision/power. If it isn't, then it seems there are problems elsewhere.
...
2
Here be dragons.
True dependencies aren't negotiable. Design before construction is such a case. However, there can be overlap. In many fields, construction can begin before the design is complete. However, once construction has begun many design options are no longer possible without (possibly expensive) rework.
Resource loading dependencies are ...
2
Don't worry MS-P is working fine. In the style of planning you describe, you may find that status is best used to help see how up to date your plan is and use Finish Variance as you already are, to see how likely your project will deliver to the timescales promised (baseline).
The explanation you ask for is:-
MS-P is looking firstly at the status date that ...
2
Managing the potential delays in advance through communication are very important. However, there should be one or more contractual requirements laid in advance to mitigate any delays on the client's end. For example, one of these requirements could give your team the right to move forward if the deadline is not met by the client.
The requirement(s) you ...
2
Like everything else in a project, "it depends".
An organization should be assigning a leader (sponsor, champion, whatever you want to call it) who will be the single point of accountability for project success. That leader needs to have real authority, and needs to be seen as a rational and appropriate choice for the role.
The project manager is assigned ...
2
Unless Management invests full authority, at an HR management level, on a project manager, then they can not lay full blame on a project manager for the project's success or failure. (And we don't really want this model anyway, since it would be an old style command and control project, not a team driven project).
However, great project managers take ...
2
I don't know very much about agile and scrum and iterations and stories but coming from a more general point of view around estimation, statistics, and human factors, I am not sure you have enough data to assert that you even have an issue of optimistic planning. You have only performed six iterations and you are only experiencing a three to five story ...
2
Thank you for the interesting question. I wonder, what is the reason people might want to take too many items into the sprint/iteration. I can think of several reasons, may be it's one of these:
team members are afraid, they will have to wait on others => they rarely co-work around items
team members need to show activity to upper management
team members ...
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.
Only top voted, non community-wiki answers of a minimum length are eligible