19

There are misconceptions around Scrum and team sizes. The first common misconception that I've seen is that Scrum mandates small teams, specifically a Development Team of between 3 and 9 individuals. Scrum contains several concepts that are immutable - "roles, events, artifacts, and rules" - and changing these core concepts would result in something that is ...


13

As the PM, you need to make a power grab play; build a case with your management that, as the PM, you need to have the authority to move resources around, including changing them out, in order to increase the likelihood of success. However, accept that fact that you may not get the power you need to really run the project. Many of us are in that very same ...


13

“It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. Sherlock Holmes A logical corollary is that it is a capital mistake to devise risk mitigation strategies before stating a risk. There is no risk in your question. Your client wants to compress UAT. Before ...


12

That's a great question. I think that one of the reasons for the attitude towards risk - washing your dirty laundry in public, if you like - is the way that risks are expressed. Typically, you will see risks in a risk register (if one exists) being expressed in terms such as: Lack of resources; Insufficient funding; Poor quality testing; Etc. By ...


12

While such a confidence check is nothing that you'd read about in Scrum Guide I don't see it as something that violates Scrum in any way. It is, in fact, answering a different question: the one about confidence of people, not the one about forecast end date. The native method to answer a question about expected end date in Scrum would be based on Velocity ...


10

TL; DR The author's leading premise is that cost containment is more important for Project A than for Project B. This is almost axiomatic if you do the math. Purpose of Project Controls Project controls are the processes and procedures used to keep a project within acceptable variance of the project's goals, especially in the area of projected cost vs. ...


9

Absolutely keep logs and absolutely bring them to the surface and work them on a strict cadence. Especially risks. Without the logs, people will happily ignore them. There is a resistance in raising and working risks, I think because of the mantra that optimistic and can do people are more successful. I have never maintained assumptions and ...


9

You've identified a risk, and a possible solution. I'd refrain from considering your solution (more documentation) as "the" solution and ask them to apply it straight away. You're working with a team of experts, which will likely have a different point of view on the matter, so do not expect to be able to "motivate" them into doing what you want... engage ...


8

The criteria you will use for assessment depend on what you, as a boss, value, on what's for you, as a boss, important. You may create a long list of them (communication, honesty, humor, transparency...) , but people will get confused, so I'd limit to few, like 5 or 7, choosing the most important for you. In my opinion more important than a list itself, ...


8

What should be my actions in this situation now? I cannot tell the client that the development of the feature has stopped because the dev went on vacation. This would be unprofessional. Honesty is the best. You don't necessarily need to mention vacation, but being up front that, due to circumstances, the work will not be completed as originally ...


8

The scrum part is irrelevant of the specific questions asked. Does it negatively affect project success? It certainly could. Losing a team member can affect both the duration of the work and the quality of the work if that person brought an expertise that can not be replaced with the remaining members. The smaller your team, the more likely you have an ...


7

An impediment or issue is something that is impacting the project now. A risk is something that might occur in the future. Typically, we look at risks in terms of the likelihood they will occur and the impact on the project if they do occur. If the impact/likelihood of a risk is high enough, we'd usually try to mitigate it in some way. This might involve ...


7

I've found 2 ways to make it work... 1) Give each PM a budget to attack risks. If a project is estimated at 2000 mandays, the PM tacks on 200 of contingency and 100 of risk management. Then they estimate the likelihood and damage of risks, and assign people to work against the risks with the highest Expected Cost (probability * cost if incurred) out of ...


7

Risk is the by-product of Assumptions and Constraints. The entire process of Risk Identification is the examination and review of what we assume is going to happen during the life of the project (Assumptions), and what are the limitations that could cause impact the project, either in execution or expected results (Constraints). Here I differ with Mark - ...


7

Firstly, you could use different methods/frameworks to run projects. Scrum wouldn't necessarily be the solution here as your prime concern is around the line in responsibilities between these two, both different and both required, roles. As well as getting the right level of communication set up. I have grasped something from the tone of your question that ...


7

@Mamoo is right. A new and junior project manager does not have the authority or influence to jump to a solution and ask the team to implement it. Even as a two decade project manager I wouldn't try to impose a solution on the team. As PM you have to help them to find their own solution. To do this you first need to get them to identify the problem. Until ...


7

You are struggling with the level of abstraction when trying to capture the risk. There is no easy format to resolve this because, and I hate to write this, it depends. The level of abstraction depends on to whom you need to escalate the risk and how you intend to treat or handle it. If the level of abstraction is too high, like driving your car can cause ...


6

As others have mentioned Agile modifies risk management as compared to Waterfall. A well managed project will include looking at risks outside the scope of the project, and these should be handled more or less the same. There are areas of risk that Agile methodology should help mitigate. Time to Market / Scheduling Error: In a waterfall project it can ...


6

Risks are typically classified into these two categories: Known Unknowns and Unknown Unknowns. You can break the latter down into Unknown Knowable Unknowns and Unknown Unknownable Unknowns. Known knowns are not risks since this implies certainty. You have two types of drivers when it comes to your budget and schedule risks. The first driver is ...


6

In my opinion any Project Manager that does not actively use Risks and Issues logs is not worthy of the name. Active management of risk, particularly, is the biggest part of what a project manager is and does, again, in my opinion. I had never used Assumptions and Dependencies logs until I started working at my prior employer where I encountered them for ...


6

I use Risk and Issue logs and review them on a strict, regular basis. They are essential tools both for myself as a PM, and for the wider stakeholder community within the project. Why do I say that? For myself, they give me focus to ensure that I address whatever could derail the project, and they make me think hard about the actions to mitigate the risks ...


6

In terms of how to do better next time: It sounds as if you identified the risk as one of medium risk (might be ready) and high severity (huge business value), and you decided to monitor the risk (communicated with him on a daily basis and the progress seemed satisfactory). Monitoring the risk basically left you in a situation of "success-oriented ...


6

Scrum doesn't blindly suggest "small teams" without qualification and definitely doesn't advocate for having a team so small that one member being sick means that work can't progress. The Scrum guide says (emphasis mine): Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer ...


5

Project Success is the Metric, All Else is a Proxy Measuring skills or teamwork (whatever that actually means, assuming you can measure it at all) is really just a proxy for measuring whether someone is supporting the project and making a valuable contribution to the project's process. Even assuming that you're measuring something vaguely relevant (e.g. a ...


5

The key is to put your energy into defining a solid MVP. http://en.wikipedia.org/wiki/Minimum_viable_product Cut back on features, not on quality. It should always be as bug free and user friendly as possible. Quality is non-negotiatiable but scope is flexible. As soon as your MVP is ready ship it. Ship it early, measure it, build another iteration.


5

Developing a Pro v. Con list is a start; however, for a decision of this magnitude, you need a bit more rigor. In other words, your analysis needs to be along the lines of benefit v. cost v. risk and you need to quantify these three categories to the degree possible. You can decompose each as you desire and score at the lower levels and you can apply ...


5

Expected Monetary Value (EMV) is an important part of risk management, usually used in large and complex projects to perform quantitative risks analysis. Probability is the measurement of the likelihood of the occurrence of any event. Impact is the amount that you will have to spend if any identified risk occurs. According to the PMBOK Guide 5th edition, “...


5

We create assumptions because we don't have the answer to a question. If we don't have an answer to a question, that means we have uncertainty. If that uncertainty is tied to an objective, it is then a risk. This mean, the moment you create an assumption, you have a risk, and it remains a risk until either you find the assumption was correct or you ...


5

I'd say it is a risk because of the possible lack of maintenance and support. For example, lack of support has a high risk on delivery because you have to figure out the solution with small or non existing domain know-how.


5

This confusion about whether something is an issue or risk is a HUGE waste of time. It comes down to how one structured the event in one's mind. Are you focusing on the current problem being experienced or are you focused on the future? Are you being tactical or are you being strategic? Are you trying to cure the high blood pressure, the obesity, the ...


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