Recently I was invited to speak and represent PRINCE2 on the Sensible Project Management Google+ hangout - a weekly video discussion organised by the Sensible Project Manager himself; Mark Phillipy.
Joined by 4 other panellists representing PMI/PMP and Agile/Scrum, we were given a project case study and each presented how we would solve the challenge applying our chosen methodology.
Although there was some brilliant discussion, there were no “winners” or “losers”. However, some interesting comparisons were made which you can see in the graphic below.
Transcript
Mark (host): Hi, my name is Mark Phillipy and welcome to the Sensible project manager hangout. Let me tell you what we’re doing here today. Elaine Jackson contacted me a couple of weeks ago and she came up with the idea getting a group of specialists together to talk about how they would approach a project challenge using their favourite methodology. So today we’ve assembled a panel. There’s going to be two people representing the PMI/PMP type of approach, one person representing PRINCE2 and two people representing Agile/Scrum. Let’s introduce everybody. We’ll start with you Alan and go across the board. Introduce yourself and tell us which approach you’re going to be representing.
Alan (Agile/Scrum):
I’m Alan Daley, I’ve been on the show a couple of times. I’m an Agile coach with a company called Big Visible Solutions and I’ll be representing the Agile/Scrum approach in our little challenge here.
David (Agile/Scrum): I’m David Hammerslag and I work with Alan at Big Visible Solutions where I do Lean/Agile coaching and consulting, thank you for inviting me here today.
Elaine (PMP): I’m Elaine Jackson, the CEO/owner of Holistic Project Management Consulting and we are located in Massachusetts. It is great to be here and to be part of this challenge and I’m looking forward to the information being shared.
Mark (host): Thank you Elaine for coming up with this suggestion, this is going to be a great topic.
Matthew (PMP): I’m Matt Davis, I’m the president of consulting services with a company called PM Providers. We’re a Microsoft partner and I’m a PMP of course from the project management institutes. I’ll be working with Elaine representing the PMI perspective here.
Mark (host): Great, thanks Matthew. And Simon.
Simon (PRINCE2): I’m Simon Buehring, the founder and Managing Director of Knowledge Train. We’re a PRINCE2 training provider based in London in the UK.
Mark (host): Welcome. I want to thank everybody again for coming, it’s been fun trying to get everyone together. I’m now going to give you the challenge, I thought we could have something that wouldn’t be “stringing one over the other” in terms of the methodologies. Each methodology will then take 10 minutes to share their approach and how they would resolve or address this challenge. When everybody has finished their approach, we will then have a discussion about it. There might be some banter in between different approaches, but it will be fun and interesting.
So here’s the challenge:
You are a Project Management Consultant and a company has engaged you to help them successfully deliver a mission critical initiative their client who is a municipality in their region. Your challenge is to describe how you would approach the project to meet the challenges and help the company deliver a successful project using your preferred project management methodology. These are the key points and challenges for this project:
- The project is to implement a solution which would replace the city's public transportation scheduling system
- The city has chosen to not go with an out of the box solution because they have not been able to find an existing solution that fits their needs which includes scheduling for bus, subway, ferry, and van pools.
- Your client will be developing the solution from ground up.
- The system will have to integrate with both the existing fair system and the city's accounting system
- Your client is an accomplished software development company which have used multiple project management and development methodologies (you can assume they are versed with your favourite methodology)
- The city has the usual constraints of budgets, time frames, etc. So there’s the challenge! Let’s start with Elaine and Matthew with the PMP/PMI approach, so take it away.
Elaine (PMP): I just want to let everyone know I was intimidated by the fact that other team had a PhD on board, so I chose to go and do some more research and have some other people help me. This is what we came up with!
For those of you not familiar with the PMI approach, we have 5 process groups and 10 knowledge areas. At each stage, the process groups and knowledge areas interact so that we can control the project. In this particular project, it wasn’t stated what was critical. It was stated as a critical project, so I assumed that everything was critical. I guess it’s better to assume because you will take a lot more precautions to identify more risk. So with that in mind, my first step in handling this project would be to get assigned as the project manager. By doing that I’d make sure that there is a project charter. This gives me the authorisation to tell team members what to do and to handle the resources on the project. I would then create a business case. Information would be needed to understand what is important, why we are undertaking this project, how the project is aligning with strategic objectives. I can make sure it’s successful. My assumptions would then lead me to creating more high level assumptions in my initial documentation, which would give me more profound information for my risk.
After writing the business case and the business charter, I would definitely be looking to get introduced to the team as the project manager. Often, teams may not respond well to the project manager. Reasons for this could be that they were friends with the previous one, or that they are not happy at the way the previous manager was let go. By being introduced by someone, you need to give this person your full co-operation. Doing so, sets the tone to the team about getting their co-operation too. I don’t know if any of you have had any of those issues in your experience. For me, there has been a real issue where the project manager is fighting for power with the business analysts or with the team members over what they need to do. By getting senior management to authorise and set the tone moving forward, it makes it easier for the project manager to establish control.
On my plan for this project, you can see that the both risk and stakeholder influences are high at the beginning of the project. For those of you who are unfamiliar with the PMI’s approach to projects, if a lot of the requirements and information while gathering the processes has not been carried out, the stakeholders will tend to be more wary of letting you handle millions and billions of their dollars because they don’t know what you’re going to do with it. But as you go through the whole process of reporting to them about the project’s progress, you’ll gain the opportunity to gain their trust. They’ll believe that you know what you are doing because you’re giving them status reports. By giving them bad news as well as good, they will know that you’re not going to hide anything and as a result they will be less likely to micro-manage you.
My next step would be to go to the department head and get their assessment of the current situation. What do they suggest as a fix, as well as the vendors that they already have in their hip pocket? Rather than …. people that have been established already so you’re not adding additional risk or pretending to know how to do the work that needs to be done. You have people that have a success rate of delivering their projects on time and within budget. If they have connections with others and come in as a team, it might be less expensive for you.
I would definitely want to assess what the most critical issue is for this project. You could have some infrastructures that are about to have a risk event, which could result in the train or the ferry carrying 500 people now having issues. Alternatively, there could be the issue of adding fuel to the environment, or leaking fuel and contaminating the water as it’s going up and down the channel.
I want to go to my last slide on here and talk a little bit about sustainability management, as I’m also part of Greenprojectmanagement.org. I wanted to make sure that you were aware that from a green project management point of view, a project has to be sustainable in order to be seen as successful. We talk about the triple constraint and in PMI we talk about time, cost and scope but also quality, customer satisfaction and risk. When we talk about sustainability management in green project management, we’re asking these questions:
- Is this project going to leave carbon footprints?
- Is this project going to leave a trail of residue, contaminating people in the area?
- Is this project contaminating the planet?
- Is this project profitable and who is it profiting - the person who’s doing the project or the people who pay to have the project done?
I’ve also listed some of the project processes and some of the issues I came up with were handicap and software needs. Are we going to have to take those into account? I also wanted to prioritise the risk. One of the areas I think that the rest of the panel may not have captured, is that when you make these infrastructure changes, will this impact the people who live in these areas? Have you thought about the emergency service vehicles who may need to travel quickly through the traffic? Will the saving of lives or properties be hampered because of the extra traffic we may be creating?
I know I only have 10 minutes, it’s kind of hard to solve a project in 10 minutes, if you’d given me two days then I’d probably be able to keep talking. I also wanted to mention evaluating the vendors using a bid analysis. You want your vendors to come up with a solution, even though they have may have done this work before. You don’t want to assume that just because they have done good work before, that they will do the same with your particular situation. I’d like to hand it over to Matthew.
Matthew (PMP): I’d like to add a couple of things to what Elaine had to say. We all talk about the “approach” or the “methodology”, and I think that if we’re trying to draw some comparisons or differences between the PMI, PRINCE2, Agile/Scrum; we should remember that the PMI approach is not really a methodology per say. It’s referred to as a framework and PMI go to great lengths to say it’s a framework and not a methodology. Although, some people turn the process groups (initiation, planning, executing, controlling, monitoring and closing) into phases. They’re not really intended to be that way and the PMI framework is really intended to act like a toolbox. There are certain tools that the PMI says that you really should use. For instance, Elaine’s first comment about having a project charter. PMI says that you should REALLY have a project charter as the power of the PM, because it gives you the authority to move forward with the project. A lot of the other tools whether it’s risk assessment, stakeholder management or communications planning; are really sort of the project manager’s choice and I really think that’s an important distinction. I’d love to hear what the PRINCE2 guys have to say about this. I’ve heard it said that unlike PRINCE2, PMI’s framework is NOT prescriptive; which means it doesn’t tell you what you should do, it tells you what you CAN do. I’m really interested in hearing the PRINCE2 stuff because it goes a bit further to say “Things you should be doing VS could be doing.” I just wanted to point that distinction out.
Mark (host): We have a little more time, anything else to add?
Matthew (PMP): To add to Elaine’s points – the charter and business case are good input. I will mention that the business case is a little outside of the framework, although PMI kind of looks at that. I think in every type of project where you see the word “public” – like in our case, public transportation, one of the key pieces you’ve got to look at is stakeholder management. I think that’s really key because your stakeholders are wide and broad. You don’t only have the hosting organisation or the purchasing organisation, but you’ve got stakeholders that include people who are walking by on the street or who are fishing in the harbour where your boats are going to be floating through. The stakeholder aspect of this can be wide and broad, and because of the public nature and the potential wide footprint of the impact; I think that it’s an area that needs a lot of focus.
Mark (host): Ok thank you, we’re going to move onto you Simon.
Simon (PRINCE2): The first thing I would suggest for this project or in fact any project, is let’s get down to some basic, core, good project management principles.
I think the first principle is “Can we justify the investment that’s going to be required for this project?” Now, this particular project we’ve been told is going to be mission critical. Somebody has taken that decision. What I would like to see, is a good analysis or explanation of the underlying business problem that we are facing here in the municipality. Also, what are the different options that we have considered for solving this problem? We need to be confident that the chosen approach is not going to be a waste of money. Having a robust business case, I think; is absolutely critical to the success of the project.
I think the second principle is that everybody who is in a position of authority in the decision making of the project, has to clearly understand what they are responsible and accountable for. In my experience there’s been lots of passing blame when things go wrong, and people not wanting to accept responsibility for things or be accountable. I think that part of the problem here is that people don’t fully understand where their authority lies within the project. When we are setting up our project management team in the very beginning, we need to clearly define what those roles are; and I’m not just talking about the project manager role. There will also be team managers and the project board. For those of you who are not familiar with the project board, it’s a higher level of management to whom the project manager reports. It’s the project board who take key decisions on the project.
I think the third good principle is “Let’s not repeat the same mistakes that we’ve seen happen on previous projects.” Let’s learn the lessons. What are the good things from previous projects we want to take, incorporate and build upon and what the bad things we want to avoid?
The fourth principle I would say is “Let’s have the right level of control and break our project down into manageable stages.” The stages will form decision points for the project board, where they can decide whether it’s still a worthwhile investment to continue or not. Therefore, perhaps the decision of closing a project prematurely shouldn’t necessarily be seen as a failure. It’s always better to end the project prematurely if things emerge meaning that it’s no longer a worthwhile investment.
Setting the right level of control and having the right number of stages comes back to Matthew’s question. How many stages we will have on a project will be determined by one of these factors. I think when breaking the project into a number of stages, we will need to weigh up the number of factors. How risky is this project? How important is it to the municipality? Although in this case we’re told its mission critical, so it should be pretty important to them. Therefore if we can assess this project as being high risk, that tells us that we will need more stages to give control to the project board.
The fifth principle would be that the board would manage by exception. In other words whoever those decision makers are, we can safely assume that they will be senior people in the municipality who have lots of other responsibilities in their normal, everyday work. Therefore, they don’t need to be involved in our project day to day. This is because they will be delegating authority down to the project manager who will be managing day by day. This means that the project manager doesn’t have to have regular meetings with the project board, which is something that PRINCE2 stresses quite highly. This is because we can produce regular reports to the board, reporting the progress and then we’ll probably have a meeting at the end of each stage reporting on whether to continue. That’s a big benefit for senior management because they don’t have to be involved day by day.
The sixth principle that we shouldn’t forget is “Don’t let our project become activity focussed.” Let’s always focus on what we’re delivering. It’s only the deliverables that are going to help the customer realise the benefits. We shouldn’t ever lose sight of the actual outputs of our project. Every plan that we develop in our project should start off with answering the question “What do we have to deliver as part of this plan?”
The last principle (and although I am the PRINCE2 person) is “Let’s not take the PRINCE2 guidance and manual, thinking that everything must be done exactly the way that it’s described.” This comes back to Matthew’s question again, which is that we have to tailor the method to suit the needs of each project. Small and low risk projects will require a much more “agile” adoption of PRINCE2, whereas large, riskier, high profile projects may require a more thorough use of PRINCE2. I think if we take these core 7 principles, while not forgetting that everything that we do; is going to help us help the municipality have a better outcome.
To add, I think there’s lots of things that we could discuss here about the differences and similarities between PMI/PMP/PMBOK and PRINCE2. The way that I see PRINCE2 is that it provides a framework for the client or organisation allowing them to establish control over what happens. It differs from Scrum, which I see more as a development methodology operating more at team level. PRINCE2 is much more than that because it enables the organisation to work with development methodologies such as Scrum and Agile, but it also doesn’t lose sight of the bigger picture:
- Why are we spending all this money?
- Why are we doing all this work?
- What is the business problem that we’re trying to solve here?
At the end of our project we’re going to be delivering stuff back into our business, which is going to change the way that we work and help the customer or the business realise benefits. If we lose sight of that in anything that we do, then we’re in trouble.
Mark (host): Thanks Simon, let’s hand over to Alan and David who will take the approach from the Agile point of view.
Alan (Agile/Scrum): I wanted to key in on something and Simon gave me an excellent Segway. He’s correct in saying that if we’re talking about pure Scrum as our Agile framework, that it definitely focuses straight onto the team and how the it evolves and works. So, we do need to apply some other ideas to help keep the big picture and goal in mind. First I’d like to set a little bit of a context, then talk about some specific things we can do to maintain that context while handling this project in an Agile way.
One of the things we have to hang onto is the vision of the product, which is what we’re trying to create here. We need to be able to talk about the benefits of the project from a big perspective, both the benefits to the company that’s doing the software development and to their client.
The next thing we need to talk about is coming up with a strategy that will support that vision. Once we have some strategy and some things mapped out, we can then ask:
- What is the first release of this software or project going to be?
- What are the pieces we can deliver soonest or within a limited time frame, to create a release that supports the strategy that supports the vision?
This release plan will then let us plan sprints or iterations. This principle has specific goals as to what they create to support the releases etc. We’re now getting down into proper Scrum, where we have daily meetings that create our daily planning level. All of these things – the vision, strategy, release, sprints and our daily meetings; all need to feed into and update each other at each level of planning. For example, if 3 months from now you realise that a certain piece of the functionality such as the ferry scheduling system is not as important as we thought, we can adjust each level and our planning as to where we want to go next and what we’ve learnt.
So, how do we kick this off and make it happen? Here’s one of the things I’ve seen to be successful when doing a project like this. We’re going to take all the teams that are expected to be working on this project. We’re also going to involve the key people in the company that are creating the project, such as the managers or even the CEO. In this case we’re also going to need to involve people from the client. In particular, because we have to connect to the existing ferry systems and counting systems, we’re going to need people from the client who know these systems already so that they can be a part of our planning. Then we can do a “release kick-off” workshop which is going to address each of the levels we have defined. We will ask the client to come in and tell us and our lead person about the vision:
- Why are they doing this?
- Why is it important to them?
- What are the benefits they expect to get?
The product managers will then tell the whole team about the strategy, the other things that we are going to do, the technology and perhaps the architecture of what’s going to happen. Then we’re going to use some tools that are becoming more common within Agile such as story mapping, empathy maps and personas. All of these things help us figure out that release level, that defines how the user needs to use the system. What are the things that a user needs to accomplish? What are the goals that the user needs to get out of this system? All of these things feed into sprint plans and daily plans. When we come out of our release kick-off workshop, the client and technology representatives will be there to help us build that product wall or map that shows us the vision of all this work. By the time we’re at the end, we can come out with two or three sprints planned and get started doing the work. Do you have anything to add David?
David (Agile/Scrum): I just want to generalise on what Alan was saying and answer what Simon was saying. Agile is much more than Scrum. Really, Agile is defined by some principles about how we do the work and involve the stakeholders and teams. I think that the breakdown you went through exemplifies that. It’s a mistake to think that Scrum defines Agile. It’s one flavour of Agile, but it’s much larger. Another thing I would add is that in this case there is an excellent opportunity to bring in some thoughts from Lean start-up. This is because we have an existing system, we can continue to get our development going and get through the first couple of releases. We could start doing some A/B testing. For selected users we could try the new system (or sub-parts of the new system), see how they compare and get early user feedback before we get the whole thing done and go live. If we take an approach where the first thing we do is the ferry scheduling, we could roll that out to select users to get their feedback; while understanding and meeting their needs.
Looking at our scenario, there’s something deficient in the current system. I’m assuming that it’s not just maintainability and that there’s some functional deficits in the current system. We can start testing to see if we’re addressing those or not.
Alan (Agile/Scrum): You’ve made a point that I wanted to add. When we come out of this release workshop, we’re going to go after small slices of the functionality. We’re not going to plan out everything that the system could possibly do. As we do our story mapping we will decide on the most important, riskiest pieces to do first. We should get the pieces that we have the most questions about done first. The ferry scheduling may be the simplest slice to do first. If we work on that, the first sprint or two would be to create some basic ferry scheduling, by doing some very basic interfaces to the counting system and ferry system; so that we can prove that we know how to do that. They might be the riskiest places so let’s make sure we can talk to those databases and systems, and work really well and tightly with the client to get those interfaces working.
We need to address that very early. Like David suggested, we’re going to make small slices, test them and prove that they are working correctly and prove that they accomplish the goals that the user needs. Then we can start asking “What’s the next slice that’s the most important?” and get down to details on that next slice. Over time we will get the whole thing built up.
David (Agile/Scrum): I think you’re bringing up a very valuable part of Agile in this scenario Alan, and that is that we will be doing demos to stakeholders as we progress. As we work through the iterations or sprints, at some level we will be demonstrating some functionality to our users and stakeholders. If we have a requirement where we didn’t understand what the user or stakeholder meant, or the stakeholder didn’t really know what they wanted, we can show them. “Here’s what we’ve created, is this what you wanted? Does this start to meet the need?” Get that feedback early when there’s still a large opportunity to make changes rather than finding that out later.
Alan (Agile/Scrum): To add. Obviously the Agile process or Agile “thing to do” is to go after priority and high risk first and understand that you are doing slices and demonstrating them as you go. I think that’s the biggest benefit you get from Agile stuff.
Mark (host): Let’s turn the discussion around where we grill each methodology for 5 minutes. Let’s go back to the PMI/PMP methodology. Panellists - any questions or concerns about what Elaine and Matthew had to present?
Simon (PRINCE2): I’d like to ask Matthew about the comment he made about PMI/PMP/Pmbok being a tool box, where the project manager can select which tools to be using from the box on their project.
When I read the Pmbok, I probably took in 1 or 2% of what it was saying because it seemed to be overly complex. I get the sense that people who come to the Pmbok may be overwhelmed by the different techniques and tools which are available and in some ways, hinder them from being effective as opposed to helping them. I don’t know what you think about that?
Matthew (PMP): Well first of all, kudos to you for reading it. I find that it’s an excellent replacement for sleeping pills. If you’re having trouble getting to sleep then it’s a good idea to read the Pmbok! Absolutely, I think it can be overwhelming because if you think “I have to use all of this stuff!” and it can be too much. In larger projects, it may be more realistic to think that you might use all these tools.
I wanted to shift a bit in terms of defending the PMI. Even though I haven’t been challenged, I feel a little defensive about PMI’s approach because if you talk about Waterfall vs Agile, the fact is Agile is a great approach for software development. In our case study here, it’s a little hard to defend the PMI/Waterfall type of approach. Having said that, if you’re talking about project delivery frameworks, one of the ways PMI allows you to get over the hump is to talk about doing things like phased approach which was mentioned earlier. Do what they would call “progressive elaboration.” This might mean taking the ferry piece for instance, going through the process work that you need to do; whether it’s some of your discovery, your initial planning, workshop, defining designs, any ground work to be able to do functional specifications - but in short iterations. In that sense, you have the ability to get away from what I think is one of the big challenges that people tend to challenge PMI with, which is “It’s big and long and it’s Waterfall, it takes forever to deliver anything.” I think that can be true unless you understand that PMI will allow you to do small iterations and “phased approach” kind of stuff. I think that helps to simplify because it means I don’t have to use every tool in the box every time I go through a phase or iteration of the solution.
Alan (Agile/Scrum): Welcome to the Agile team Matthew!
Matthew (PMP): It’s true, it’s hard to defend Waterfall stuff especially in the software development environment. However, it doesn’t mean that you can’t apply some of the disciplines that the PMI suggest.
David (Agile/Scrum): One of the things that jumped out to me is the difference between the PMI and traditional approach, was with the PMI approach I was hearing lots of command and control kinds of conversation; as opposed to Agile/Lean which is more collaborative, and you keep an eye on the people doing the work and involve them on getting the plans up. I don’t know if I was reading into things I was hearing or if that’s how PMI is? The idea comes out of the “Toyota way”. The people doing the work are the ones who will figure out best how to get that work done, if you give them a clear vision with boundaries.
Matthew (PMP): I think there are some conflicted aspects of that. Certainly, there’s this concept of “The project manager shall be the leader and go forth with leading the project”, vs Agile which is more about the teams doing the work. Then again, PMI does tell you that as well but when it comes to doing things like work estimates, developing schedules, understanding work packages or work breakdown; it says that you need to use your subject matter experts. You shouldn’t assume that just because you’re the project manager (and we all know that most of the time you’re not necessarily the expert in a given area!) but you’re the orchestrator expert. I think there’s a balance there but I feel that sometimes there’s conflicting messaging from PMI.
Simon (PRINCE2): If it makes you feel any better Matthew, the criticism that is level with PMI/Pmbok is also the same one which is levelled at PRINCE2.
PRINCE2 is also seen as the old-fashioned, top-down,” big design upfront” kind of Waterfall approach. It can be and it has been used like that, but it doesn’t have to be. The fact that one of the seven principles of PRINCE2 says that you should tailor the method to suit your needs, means that it’s incredibly flexible. One of the weaknesses of PRINCE2 is that there’s actually only two techniques in there. There’s a whole load of tools, techniques and methods which you have in the Pmbok which we don’t have in PRINCE2 and as PRINCE2 Practitioners and project managers, we should take them and use them.
I don’t want to seem like I’m sitting on the fence here by saying that both Pmbok and PRINCE2 are good! I also think that Agile stuff is certainly something that should be used by the project teams. I’m all in favour of empowering the teams and the people that know the work, to get on with doing it. We still have to set that in an overall context of understanding why we are doing it and whether we are going to realise the benefits of investing all this money.
I have a question for Alan and David about Agile. This particular challenge is a software project and that’s where Agile has come from. Other than software projects, which projects do you think Agile is best suited for? For example, could you use Agile building a 40 storey skyscraper?
Alan (Agile/Scrum): I’ll do better than that! Look at the history of the Empire State Building. If you look at how it was built, the plans for each floor were only drawn just before they built the floor. The people that were building them were so skilled that they didn’t need to have a big design upfront. They made an overall plan that they presented to their investors, but they actually built all the details as they went. It was essentially a Kanban system as they built that building. They had it all down to a science where trucks were arriving once a minute and getting unloaded with materials, and they would plan storeys just before they built them. So yes, you can use Kanban and Agile methodologies to create physical products.
I’ve seen Scrum, Agile and other Agile methodologies applied to marketing, sales and teaching. My first experience with Agile was creating hardware, military SSD’s (solid state drives), where we had both firmware (which is software and programmable hardware) and hardware, and we would integrate that altogether to do it be as Agile as we could. I think if you look at the Agile manifesto it’s more about ideas, philosophies and mind-sets. Those ideas of mind-sets, philosophies of collaboration and creating small slices that you’re delivering quickly, can be applied to many different types of work. However, they are not that they’re perfect for everything.
David (Agile/Scrum): I’ll second what Alan said, but I think a lot of that is Lean development and methodologies. I think that in many ways, Agile is Lean for software. If you’ve got that kind of focus, you can apply that in many places. If you’re thinking about constructing and building, you have to apply intelligence. For example if I’m building a super-max prison, I’ll need to do a lot of work upfront, figure out where I need rock-solid walls and where I don’t; and what kind of security features I need to have. At the other end of the spectrum, if I’m building a hunting shack in the country, I probably don’t care too much about what the foundation looks like because I can make changes easily and move the plumbing around without too much trouble. So, you have to scale the amount of upfront work that you do to the project that you’re doing.
Mark (host): Simon you made an interesting point there, I was very purposeful on how I came up with the challenge and I didn’t want to “walk anybody out”. I know that Agile (especially from the Scrum point of view) is really embraced by the software industry and there’s reasons for that. But in the challenge, I also wanted to bring in the fact that this was a municipality. I have some questions. If I understand PRINCE2 correctly that it grew up from the UK Government, from the Scrum point of view I’d have a tough time seeing a Government agency being Agile enough to take on Scrum. What do you guys think about those two things?
Alan (Agile/Scrum): I’ll jump in. There’s an interesting conundrum that we have very often and this is not even in Government work. Traditionally, most contracts and projects are structured to be fixed scope, fixed budget and fixed schedule. Which is to be expected especially within Government. The difficulty that I didn’t address as I was talking was the cultural difficulty.
- Is this client willing to allow us to deliver them slices of functionality with the understanding that we’ll do the most important stuff first, but when the money or schedule runs out they may not have everything they wanted to start with?
- Are they willing to be a participant in the project?
- Are they going to be there for every demo?
- Are they going to be there to provide us feedback so that we really are giving them the value that they need, even though we haven’t promised to give them all of the scope within a fixed time frame?
There’s a huge discussion to have there with your client about these trade-offs between fixed time, fixed scope, fixed schedule and those kinds of things, to help them realise that we are going after value first and not everything in the kitchen sink.
Matthew (PMP): It’s actually one of the areas I’ve had to think through with customers in terms of some of the challenges. For instance, annual budgeting and funding. How do I do that with an Agile development environment if I’m doing this “rolling wave planning” from a PMI perspective? It’s time for me to go to annual budgeting maybe around this time of year, or this month for a lot of people. How can I do that if you’re not going to tell me what it costs to deliver X, Y and Z functionality over the course of the next 12 or 18 months? I wonder how you handle that.
Alan (Agile/Scrum): What you have to do is change the conversation, by producing results. There’s two things that happen and one is because I’m producing results early, people actually get to use stuff and they’re less worried about holding me to the fire to get everything. The second thing that tends to happen is that we need to have a conversation about how their participation helps drive the direction of the project. I haven’t found yet that if I take a traditional project manager who loves gantt charts and 1.5 year plans that never change and get them to be honest, they’ll tell me that the plan changed, that there was a feature that they never delivered and that no one complained. The truth is, everything changes. Agile just makes this explicit and a lot of people have a hard time with facing that reality.
David (Agile/Scrum): I think that there’s a point lurking in the back of what you’re saying. For example, we start out and the customer tells us that getting the ferry scheduling is most important and after that it’s van pools, so we go and do the ferry scheduling, look at it and say “wow, that’s great but we decided that we don’t care too much about van pools now, we care more about bus schedules than we do about van pools.” We haven’t really scheduled anything out in far or great detail so we’re going to be agile and adapt our schedule to the customers changing priorities. As they start to see the product and value being delivered, they understand that they’re going to change their minds. What they said they wanted 6 months ago, is not what they want today. I’m sure you’ve seen that, Matt.
Matthew (PMP): Well alright. Another thing that the PMI stresses is one of these “must-haves” is to have some type of change management capability in place. We all know that change is the one constant. We’re all going to get it and you need to have a way to deal with it. I think from a PMI practitioner perspective, what that means is that it’s inherent but there’s also overheads associated with that and it’s not instilled within the framework. It’s something that I have to go “Oh! There’s a change, I’ll have to go and manage it” as opposed to (even though we were anticipating it) it being viewed as variants, something that is different from the plan. That may be a subtle difference but I think you feel it when you’re either participating in or being part of a team that has to say “Oh! Change! Hold on! Time out! We’ve got to assess and understand this”. It’s may be less fluid than in an Agile environment but it’s a required component to be able to use a PMI type of approach, because we all know that change is absolutely going to happen.
Simon (PRINCE2): Well, project managers have always had to grapple with the three sides of the project triangle: time, cost and scope. If you increase one side, it’s going to increase at least one of the other sides. The approach that PRINCE takes is that it understands that you can’t predict some of these things so precisely. We can’t precisely predict the time or the cost, but it goes beyond them and says that there’s actually 6 things which we should really be managing here. We’ve got time, cost, quality, scope, risk and benefits. PRINCE has the approach of enabling each level of the project management team to set tolerances for each of these six targets. For example, you might be able to overspend or underspend on cost, or deliver a little late or early. These tolerances are set by each level and enable more control from each level to the level below. I think that’s one of the good things about PRINCE2. I think that means it can also work with the Agile stuff at the team level because in the Agile sense, you have no concept of time-tolerance. You have the sprints where you’re going to deliver the next iteration and there’s no way that can be late. What you DO have within Agile is the concept of scope tolerance, so you take out the features if you’re not going to be able to deliver those at the end of your time slice.
Alan (Agile/Scrum): That’s an exciting aspect of PRINCE2, Simon. I enjoyed hearing about that so I’ll have to go looking into that a bit more. I like that they have these sliders that say time is most important and budget is less important etc.
Mark (host): We’ll have to wrap up now. Thanks to all of you for participating, I’m guessing we’ll do something similar not too far in the near future. I learned a lot from this. Let’s go around the room and share our last parting comments and let people know how to contact you.
Alan (Agile/Scrum): I do want to say that some of the most meticulous and smart people that I have encountered are project managers. Whether they are traditional or Agile, if they can apply the skills they have when looking for things and watching how a project moves, it’s a good benefit to have. Particularly, I’ve appreciated learning more about PRINCE2 in this session and thank you for your time everybody. I can be found on Twitter as @dayleyagile, Alan Dayley on Google+ and email .
David (Agile/Scrum): Thank you for inviting me to participate this morning, I’ve learnt a lot and it’s been a lot of fun. The one parting shot I would add is that I think that there’s something about the traditional PMI perspective (and I suspect this of PRINCE2 as well) which I think Agile could learn from, and is the risk management aspects. It’s built into Agile but I think that having an explicit focus on your risk monitoring, understanding how you’re buying down your risks as the project progresses which comes more from those traditional methodologies, is where Agile could take a lesson from. Feel free to email me at .
Matthew (PMP): Last parting comments. I guess I’ll just say that I think a lot of the PMI folks feel a little “back on their heels” sometimes and probably rightly so. Not that long ago, Gartner reported that by 2015, 80% of all IT companies will have shifted to Agile methods. I can feel you all gloating right now! It’s a fact, Agile has tremendous value. I think we all need to recognise that, adapt and understand that customers are looking for faster, better, quicker, easier etc. Certainly, Agile does a lot of those things in that regard, so kudos to those people who know how to deliver that. There is still a place for the traditional stuff, but PMI is adjusting as well. They’re recognising that the place of project management is shifting and I think that’s a good thing. In terms of contact, the easiest place to find me is on Linkedin and
Mark (host): Just to point out your comment of “Agile is taking over the world”, we all know that it is making great progress. I’m actually a Scrum Master as well. I’d like to refer people to a hangout I did with Joseph Flayiff entitled “Being Agile in a Waterfall world”. Really, I think that’s the situation we find ourselves in and part of the discussion we’ve had here is that we are forced into a Waterfall world because of the environment or culture, but yet we can still pull in Agile concepts or principles.
Simon (PRINCE2): Thanks Mark for inviting me, I’ve really enjoyed this chat. I enjoyed what Alan was saying in particular, about the use of Agile and Lean to the building of the Empire State building. That was a fascinating little example which makes me want to go and read more about it. I don’t think that any particular approach has all of the answers, all of the time. I think that I’d prefer to say that some of the approaches have some of the answers, some of the time. Saying that, I’m going to continue to sit on the fence and say “Let’s all use a bit of each other’s type of approaches to help us to deliver at what the end of the day is most important, which is to deliver something which is of benefit to our customers.” You can contact me on Linkedin, Google+ or email me at .