5 Risks To Your Project Resource Management
Project resource management risks are often overlooked when it comes to putting your risk register together, but here are 5 risks to consider when securing your team.
1. It Takes Longer Than Expected To Get The Team
Your project plan probably says when your project is due to start. And if it doesn’t, your project sponsor is sure to have an idea, probably as soon as possible! However, you can’t always control how long it is going to take to recruit all the members of the team, and a major risk to your resource management is that it takes longer than you expect.
This could be because there are political reasons to finding the right person, or just that it takes a long time to get the approval of line managers and for them to agree to release their staff. It could be because you don’t have the right people in-house and you have to hire them externally. If staff have a notice period to give to their previous employer it could be anything up to around 3 months before they are available to work for you.
The danger here is that by taking extra time to recruit the full team you cannot start the project at the time you expect. You may still be able to start some work and have to delay the start of other work because you do not have the relevant team members. Make sure you flag this risk to your sponsor as soon as you realize that you are struggling to get the team in place.
2. Key Team Members Are Only Part-Time
You may find that a critical member of the project team is only available to work on your project on a part-time basis. This sometimes happens when skills in the company are limited and there are two high profile or critical projects taking place at the same time. The key resource then has to stretch his or her availability over both projects, meaning that they are only available to you for some of the time. It might get even worse during busy periods on the other project, as their availability may drop below 50%.
There isn’t much you can do about this except try to find someone else to replace the key resource. Often that isn’t possible, so plan extra time into the schedule to enable him or her to complete their work over a longer period of time.
3. Not Enough Staff Available
You may have scheduled your project based on being able to get enough people, especially for busy periods like testing, when you may have to bring in extra pairs of hands to get the work done. However, when it comes to those tasks, you could find it difficult to get the extra people you need.
Generally, project teams are often having to do more with fewer resources these days, so it could be impossible to get the optimum amount of people for the project. If that happens to you, you’ll just have to do the best you can and accept that the project will take longer if you can’t get the resources you need.
4. No Skilled Team Members Available
Another resourcing problem is not having the right people available. You could have plenty of people to choose from for your project team, but if they don’t have the right skills then they are of no use to you. It’s important to get a mix of both enough pairs of hands and the right skill set, otherwise you’ll end up with a large team that can’t function because it doesn’t have the correct skills to move the project forward.
In other words, you don’t just need people, you need the right people! Log this on your risk register as there is likely to be a time in the project where you are missing key skills. You can mitigate this by identifying the required skills early and then sourcing them as soon as you know they are needed.
5. Team Needs Time To Learn
Your project team may well need time to learn new skills – skills that no one has in house and that you couldn’t recruit for, or that it wouldn’t be cost-effective to recruit for. An example of this would be the use of project management software. Many project management software tools are very easy to use and need little or no training. But some can be unwieldy, and if that’s the sort of product you use, then you’ll need to allow some time in your project schedule for them to learn how to use it.
This is the same for other software, hardware, programming languages or techniques or business and project management processes. In fact, anything that someone on the team hasn’t had to do before is a learning opportunity, and you should plan in extra time in the schedule so that they have a chance to get up to scratch.
Resourcing your project can often be difficult, and my colleague had to settle for second best with a couple of the people on her team – she couldn’t get the experts she wanted as they were busy on higher profile projects. However, resource risks can be overcome and managed effectively if you are aware of them and the risks that they might present to your schedule. She ended up scheduling in extra time and booking a training course for one of the team members who isn’t so experienced. As a result, the company has gained a valuable additional trained resource and she has a project schedule that is achievable with the staff she has on the team.
Credit: projectmanager.com
How to Estimate Velocity As an Agile Consultant
Many of you work in a dedicated in-house team, but some of you contract with companies for Scrum and agile consulting. One problem that sometimes arises as an agile contractor is when the prospective client wants an upfront commitment on the scope of the project, but the Scrum consultant feels there isn’t enough info to estimate a backlog for the RFP phase. Add to that the fact that you are either estimating on behalf of other teams, or your own without prior history of the project, and it can be challenging.
So what then?
This challenge really comes down to being able to estimate velocity even in situations that aren’t cut and dry. Chapter 16 in the Agile Estimating and Planning book talks about this.
To be clear, points are relative, and it’s hard to compare teams, but if a team builds project A, then is about to start project B, we can use their A velocities to predict B as long as the points are consistent across projects. If a 5-point story on A is expected to take as long as a 5-point story on B, use the historical velocity.
The problems enter when a team has no velocity data.
What to Do if You Already Have a Team Assembled for the Project
Let’s assume you have the team – they just don’t have any velocity data. Have them estimate the required stories in story points the normal way, even if they have no idea what their velocity will be. They do know, however, that the sum of the stories is, say, 300 points.
Now, have them plan a sprint.
My preferred way to plan a sprint is to grab one story, split it into tasks, estimate the tasks in hours and ask the team if they can commit to finishing it. Then repeat with additional user stories until the sprint is full.
Suppose a team does this and commits to stories X, Y and Z. They couldn’t have discussed velocity, as they have no data. But, they do have points on all stories including X, Y and Z.
So, look at the points on those three stories, add them up, and that’s a starting point for velocity. If you can, get the team to do this again by planning another sprint that way and commit to M, N, O and P, which is probably a different number of points.
Use the two values as a range. Say 18 to 22 points. Maybe adjust those based on your intuition. If you think the team, like most teams, is about to overcommit in their early sprints, use estimates a few (or many) points lower based on your judgment, but based on what they came up with.
What to Do if You Don’t Have a Team Ready to Go
Let’s make the situation worse. Let’s assume you don’t even have the team yet. You’ve got plenty of employees, but you don’t know who will do this project. Get some representative people together and have them pretend to be the team and do the steps above.
Then you can tell a boss or customer “a project with three senior programmers, a senior tester, a junior tester, a good designer and a great database person can do this project in X sprints.”
Or make some adjustments based on differences in how you think you’ll really staff it; change the three senior programmers to be two or more junior programmers and lower the velocity based on your expert opinion.
Using data from other teams can help. I like to make these types of predictions with velocity ranges. Suppose you have other agile teams. Calculate the relative standard deviation in velocity for those teams. (Relative StDev is just StDev but expressed as a percentage.)
Average those relative standard deviations over all teams. Say you have teams with 15 percent, 20 percent and 25 percent. That’s an average of +/- 20 percent. Use that for the new team. If they estimate velocity as 20, you could add + and – 20 percent.
Often though, I’ll take the estimated velocity as the high value and go down by 40 percent, just given the likelihood of teams overcommitting.
Credit: mountaingoatsoftware.com
