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 ...
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 ...
6
Aside: I may be reading too much between the lines of this question; I think this is a workplace politics problem rather than a strict PM problem. As a consequence, my answer is correspondingly pessimistic, jaded and cynical.
What is the probability that the functional unit will fail to deliver? What is the impact on the project scope/schedule/quality?
...
5
This speaks to pessimistic targeting on your estimations. Sounds like the team has a long runway and, as Parkinson's Law suggests, the team is taking advantage of every bit of it. There's another phenomenon, as well: Student Syndrome.
Challenge the team: target more aggressively. Cut your durations and bring your dates in at baseline time.
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 ...
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
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
Add buffer to your project. There are two ways to do this:
Either taking a Critical Chain approach and have a bucket of buffer for the whole schedule (this would be my recommended approach), or, for a more quick and dirty approach...
Add time between the delivery date and the start of the next task.
This kind of situation is dealt with extensively in the ...
4
Think of schedule compression as the elasticity of the work. If you have zero compression opportunities, you have no slack in the schedule. Anything along the critical path slips to the right, all the activities along that path slip to the right.
What the manager needs to know about schedule compression when asked What is your schedule compression is how ...
3
How do you calculate schedule compression ratio?
From McConnell's book, Rapid Development, he describes compression ratios from researches involving hundreds to thousands of projects. So I think you can't just calculate the compression ratio of one or two projects, as you can't know how much the project would cost without the compression.
Another method ...
3
This sounds pretty normal. You have moved from a position where someone told you both what and the scope of what you were doing to a position where you have to decide those things for your self. It's not easy.
I'm an industrial engineer who moved from a consulting firm to a production management position with a startup. I went from being handed projects to ...
3
A standard approach to conduct audits will quickly turn into a useless control that everyone will be scared to stop using but no one will use the data from it. If I were you, I'd develop my audit approach consistent with the goal I am after as well as the project and its unique set of issues and risks.
I can see a checklist to sort of bang any project ...
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 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
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
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
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 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 ...
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
