On this blog I’ve looked at different Knowledge Areas and how they apply to us as project managers, and also taken a budgeting and cost focus on a lot of articles. But what if you are managing an agile project? How do some of the financially-leaning Knowledge Areas work when you are working in agile ways?
Here’s how. Today, I’m looking at how the schedule management Knowledge Area applies to the agile work process.
Project Schedule Management
When you work in an adaptive environment, your project schedules aren’t going to look like big old Gantt charts. You’ve got short cycles to do the work in. With a lot of the people I mentor, we’re talking two week sprints.
The short cycles allow you to do work, review the work and then tweak the results as necessary, including any testing that needs to be done. Ideally, you don’t want all your features dropping on the testing team on the last day of the sprint because that’s not kind!
One team I worked with had this problem a lot so actually set up testing sprints running ‘behind’ the development sprints, just so there was enough time to test everything. Whatever works.
Scheduling is a cost-driven activity because people cost money, and you need people resources to do the work. That’s why it’s important to understand what scheduling options are available to you and how best to get the most out of the time and people that you have.
This could look like pull-based scheduling – which is what I am doing on one Agile team at the moment. There are a lot of tasks. I have the luxury of being able to decide on my next task. They all have to get done, and I can choose. Within reason!
Or it could look like on-demand scheduling. I have used a scheduling approach on a predictive project where we only planned the next three months in detail and let the rest of it unfold as we got closer to the date. It was the only way to stay on top of the work, on that monster project. It wasn’t a project being run with agile principles, but our just-in-time approach to scheduling made our lives easier. As I said, whatever works.
If you work in a big company, there are probably predictive and adaptive methods in use. All of the projects need to fit into some kind of PMO roadmap that allows the business to strategically plan the change effort.
The Agile Practice Guide talks about using predictive, adaptive and hybrid approaches to combine practices to get the best approach for the project or programme being delivered. Consider what scaling you would need to do to your current methods based on:
However, good schedule management skills are universal, and being able to break down the work, estimate, ensure work is given to the right task owners, track progress against tasks being completed – all those are fundamental skills. The tools and techniques you use to do them might be different depending on whether you are taking predictive or adaptive approaches.
Your PMO should be able to support all kinds of ways of working, and if they can’t yet, they are probably thinking about how to make sure they can in the future, because more and more PMOs are needing to adapt the way they work to be able to better support agile project teams.
From a financial perspective, you should be able to track the resource cost (and any other costs directly related to scheduling, if there are any) via timesheets or the equivalent way of reporting actual hours worked. This is especially useful if your team is not 100% dedicated to your project. If they are only doing your project, and you’re running on a timeboxed approach, you should easily be able to work out how many hours it took you to get the output from this timebox.
Schedule Management as a Knowledge Area is applicable to project managers working in agile environments. As with all tailoring, you take what you need and adapt to the project, team and processes you are using.
Pin for later reading:
Are you working with suppliers on your project? Chances are you probably have – or if your current project doesn’t require external contractors/suppliers, then one in your future probably will. These days, it’s common to have suppliers partnering with you on a project because companies choose to outsource work to those who are specialists.
However, a lot of project failures begin an end with customer relationships breaking down between you and the supplier. I remember one (huge) project we were going to work on and we had a supplier in mind. They were lovely people as well as being specialists. We were at the point of signing their contract and then… the deal fell through. I can’t go into the specifics of why, but suffice to say that as a project team that gave us a big problem. Our preferred supplier was no longer available, and we needed a replacement fast.
In hindsight, that was a great project for learning about contracting.
Building collaborative contractual arrangements
When you set out to nail your suppliers to the ground, and get the most out of them for the least possible price, you are setting yourself up to fail. Not only is not ethical business practice, it puts your project at higher risk because you are creating a ‘them vs us’ or ‘winner vs loser’ situation. Be a nice client.
Taking a collaborative, partnership approach is something that will be common to many of you, including those on agile teams. I’ve worked in partnership with suppliers over several projects and many years. It’s always best for team harmony and productivity, and project success, for the supplier to be fully involved, supportive and partnering with us as part of the core project team.
Let’s say you want that for your project, but you still need the formal boundaries that come with having a third-party relationship with another company. Here are some contracting techniques that you could consider as the building blocks of your relationship.
1. Multi-tiered structure
Be more flexible. Document different elements of the project in different documents. You can have a master service agreement and then add on extra elements as the project progresses. Then you can amend the schedule of services to meet your current needs. Use a statement of work if you need more formal ways of defining scope elements etc.
Having a more flexible way to procure services makes it easier to make changes and gives you more options with how you work together.
2. Focus on value, not progress
The contracts I have been involved with have all hinged on having fixed milestones based on delivery or phase gates around when certain moments come to pass on the project. That’s OK, but you can also look at staggering contract payments based on the delivery of value instead of particular artefacts. That’s something I would look at for future contracts. If you are focused on value-driven deliverables, there is more incentive for you both to be agile and flexible to achieve the goals.
3. Price by increment
Another suggestion is to have flexible pricing based on smaller aspects of the project e.g. user stories, instead of one big payment for the whole thing. Fixed time and materials contracts are not something we use very often because they tend not to work out for either us or the supplier. If you know exactly what you are buying, and they know exactly what they are delivering, perhaps that will be OK. But for the kind of work we do, it’s more helpful to have a fixed price plus add ons for extra things. It gives us more control over how money is spent and lets us change our mind (with agreement from everyone) later in the project if necessary, without putting a financial burden on the supplier!
4. Cancellation options
Consider adding in cancellation optiosn that let you both escape the contract early. But build in enough notice for you both to make a graceful exit. One contract we gave notice on had a 3 month notice period. Given that it was a legacy system, in use for years, and with multiple integrations, it was difficult to extract ourselves in such a short period of time!
Another way to look at this, especially with agile work in mind, is that you should be free to exit a contract if you have got enough out of it. For example, let’s say you contract with a supplier to do a bunch of work, but you get to a point where you’ve achieved adequate business value from only half of the original scope. You don’t need to go any further, so you should be able to exit at that point. If the project contract has been written effectively, hopefully the supplier will not be at a loss either – you’ll want this to be a collaborative discussion. A cancellation fee could offset some of the inconvenience to the supplier, while still ‘getting back’ money for you.
5. Fund the team, not the deliverable
Another flexible way to build a solution that meets your needs in an agile team is to embed the supplier’s expert resources directly in the team. You basically buy in the skills you need, for the time you need them. They work alongside you, on whatever scope elements or user stories are at the top of the priority list. Then you are reserving the right to change scope or make flexible direction shifts, while still working with expert supplier resources.
This option works if you need what’s in people’s heads, or a spare pair of hands – but it’s less useful to you if your project is using what the supplier makes themselves.
There are other ways to look at collaborative contracting and the Agile Practice Guide has more information on alternative ways to have formal, but flexible, relationships with third parties.
Pin for later reading:
What is Depreciation?
Depreciation. It’s something that you have probably heard about but might not be using day-to-day in your work as a project manager. However, if you are working towards the Project Management Professional (PMP)® exam, then you might already know you have to understand the basic concepts of depreciation. You might get asked a question about it.
So what is depreciation? I write a lot about different financial aspects of project cost management on this blog but I don’t think I’ve ever covered depreciation before!
Depreciation is a way to split the cost of an item over the life of the item. It is why some insurance companies will only offer you a like-for-like replacement after a loss. If your television is 10 years old, they will pay out on the value of the 10 year old set, not the cost of a new one (which is silly, as you are most likely going to buy a new one, not seek out one that is 10 years old – but that’s a different conversation!).
Depreciation is an accounting treatment that allocates the capital cost of a purchase over the life of the item purchased. If your goods have a finite lifespan – let’s say that TV was going to last you 12 years – then each year a bit of the cost gets accounted for. You are ‘spending’ the cost of the item over multiple years.
Straight-line depreciation has this name because if you draw the cost of the asset on a graph, you get a straight line. You depreciate the overall cost by the same amount every year, based on how long you say the asset will last (this part is accounting magic – your Finance team may have guidelines on how long an asset will last in the world of finance.)
Here’s an example.
Let’s say the lifespan of a computer is 5 years. You buy the computer at the cost of £5,000. First we need to workout the rate of depreciation. £5,000 divided by 5 years is £1,000 a year. That’s 20% of the total cost. So the value of the computer depreciates by 20% each year.
You can see how the straight line appears on the graph below.
There’s another type of depreciation to learn about too.
Double-declining depreciation works on the same principle, but the value declines doubly fast (as you can tell from the name). So in our computer example, the rate of depreciation isn’t 20% per year, it’s 40%.
But – you don’t take the flat 40% off each time. Instead, you take the 40% off the new asset value.
In the first year, you take 40% off the price paid, leaving us with £3,000. This becomes the new asset value. In the following year, you take 40% off again – but off the £3,000. That brings our asset value down to £1,800.
And so on.
When you get to year 5 in this example, you actually have £388.80 left. That’s the value of the asset at the end of its lifespan, and what you would want to try to recover if you sold it as scrap (note: don’t try to sell company computers as scrap, that’s now how to dispose of them!).
The graph of depreciation for our laptop now looks like this.
That’s quite a drop off in year one, and then it levels out a bit as it gets more and more worthless – you know what I mean.
Why you need to know about depreciation
Depreciation is a useful concept to understand when talking to finance people about the assets your project is buying or creating. It’s not something I use day to day, but you might come across it in financial projections for your projects, for example in the business case or forecasts.
Understanding the concepts will help you better understand the way your project is being costed and budgeted.
Pin for later reading:
Standardising the Language of Risk [Video]
How do you talk about risk? Do you talk about negative and positive risk, or threats and opportunities?
And do your colleagues use the same terminology? As a project manager, we need to be able to have conversations about risk – and make sure that the people we are talking to understand what we are talking about! That can be hard to do if you don’t have a standard risk language – terminology that everyone in the business understands.
In this video I talk about the benefits of standardising the way you and your team talk about risk because. With standard vocab you can gain better buy in for your risk management actions because people get what you want to do.
It also allows for comparability between risks between projects, programmes, portfolio and the enterprise level. By all using the same definition of ‘major’ to describe a risk assessment, for example, you ensure that everyone understands the same thing.
This video talks about how to have a conversation about standardisation, and what you can do as a project manager even if you think you aren’t in a position to influence corporate standards on risk.
Pin for later reading:
What is Project Cost Control?
Categories: cost management
This question: What is project cost control? comes up quite a lot. I’m not sure exactly why, but I think it’s to do with project managers wanting to make sure they are putting adequate measures in place to monitor and control spending. After all, it’s not our money. We are responsible for making sure it gets spent in a way that supports the project’s objectives and is fiscally responsible. It can feel like a lot to ask.
In my experience, it is actually easier managing huge sums of money than it is managing smaller amounts. On a teeny budget, every dollar counts. The larger the budget, the easier it is to manage because you have latitude to make decisions within your control and tolerance limits, such as approving an extra $50 for something or dealing with an invoice that’s 10% more than you expected. Having financial responsibility is a good way to help manage roadblocks and get things done on a project.
OK, so what do we mean by cost control? Generally, we’re talking about processes to do with:
All of these help to ensure the project can be completed within the approved budget.
One of the biggest areas of focus for cost control is budget tracking.
What do you track in a budget?
Let’s say you’ve started the work. What is it that you should be tracking through the project?
You can track:
Actual expenditure itself is a bit of a vague term because it’s often used to encompass three other terms:
Tracking budget KPIs
Another part of cost control is making sure that any financial reporting for the project is complete. Cost is normally a big factor in deciding whether the project is on track for success or not – I’ve certainly found execs to be very interested in the cost performance of projects, especially the larger budgets. They want to know the money is being spent in the way they expect and that we’ve got enough of it to get to the end.
Cost is typically a key performance indicator, but you might find it worthwhile to track other budget related KPIs. In a programme, you might track return on investment for projects that have completed, for example.
Who does project cost control?
The project manager is often fully responsible for project budget management, but you could also have a Finance person attached to the project (I had this once – he was great). Depending on the size of the project, and the size of the budget, you may be able to have someone on the project’s senior team leading on cost tracking.
Your corporate Finance team will also be involved, even if much of the day to day handling of invoices etc comes to you. They may rely on you to approve invoices (because you are best placed to confirm the work is complete) but they’ll be processing the payments in operational systems and checking they have been correctly posted to the right cost centre for accounting purposes.
Another part of cost control happens when the project is formally reviewed. The review happens anyway, and cost is part of the discussion, and part of the decision about whether the project is still viable.
One of the factors to take into consideration is sunk costs – costs that can’t be recovered because they have already been spent or committed including costs that would be incurred if you cancelled a contract or similar.
However, execs sometimes look at sunk costs and think they must continue the project because they’ve already spent money on it, even if all other signs point to the project being stopped. The viability check needs to take that into account: but why throw good money after bad? If you can’t salvage the project, don’t spend more on it just to get it to ‘done’. That would continue to be a waste of resources.
The project manager’s role is to input to these kinds of discussions with full facts and an approach that draws on commercial acumen, so the team ends up making the right decision for the future of the project.
Planning for risk
Finally, cost control also involves planning for financial risk – in fact, planning for any type of risk.
Dealing with risk costs money, because you’d want some kind of budget to pay for risk management actions such as mitigating the potential problem. Risk and issues can mean paying out for things you didn’t expect to have to fund.
The more risk budget planning you can do, the better prepared you will be, and the less likely it is that your overall budget will suffer. You’ll have more time and money to deal with the problems because you planned for them.
Pin for later reading: