I knew I had a big problem when I walked into the new programme space and found 18 desks. 18 wasn’t enough. I predicted I would have about 35 people on the team and I wanted them together. Co-location is so important to me that I will always challenge the assumption of “there is no space”. And I have found there are lots of things I can do to get my team together.
Continue reading
Tag Archives: programme management
When Buckets Go Bad
I use the term Bucket Planning for Release Planning. The metaphor works because buckets overflow if overfilled. There are risks associated with Release buckets corresponding to Minimum Viable Products (MVP). A large MVP bucket has gone bad and a MVP Bucket that continues to grow is a Bucket gone really bad.
Continue reading
Bucket Planning – Helpful Metaphor for Agile Release Planning
I sometimes call a Release Plan a Bucket Plan and the process Bucket Planning. I like the metaphor because if you overfill a bucket you end up with a mess on the floor – and the business gets that.
Continue reading
Reporting Percentage Complete on an Agile Project
What do you do when management asks for a percentage complete on an Agile project? The flippant answer is “tell them the percentage complete”. Agilists reject percentage complete when reporting on low level stuff. But for the project as a whole you can get quite an interesting metric, one that is based on real data, so why not calculate and share it.
Three Ways to Control Scope in an Agile Programme
I both embrace change and also fight like crazy to reduce scope creep. On my current programme I use three main techniques to control scope: Programme Vision, Release Goal, and Requirements Trade-off. In different ways all of these put the business in control of what is in/out of scope. But they all help me stay within budget and time constraints.
Continue reading
90% Complete not = Done
What do you do when a developer claims “I’m 90% complete”? Well, don’t rely on it and patiently wait for 100%.
Continue reading
The Sign Off – An Example of Delegation and Decision Making
I had just joined a team as programme manager and was talking to the lead user experience (UX) designer about the latest version of the UX design. We’d not worked together before and this was the first time I’d seen the designs. They looked pretty good to me and I told her so. That is when it got a bit weird.
PgM: They look great.
UX: Okay, I’ll get everybody together to get sign off on the designs.
PgM: Um, who is everybody?
UX: <Lists names of the business representative, product manager, technical architect, business sponsor, technical sponsor, UX discipline lead for the department, development manager, portfolio manager, team assistant to take notes, and quality manager>. I hope they don’t want too many changes.
PgM: <Jaw drops>
Risks, Assumptions, Issues and Dependencies – Don’t Get Smacked in the Face
A RAID log is used for tracking Risks, Assumptions, Issues and Dependencies. To be honest I see more similarity than differences between these. They are all about threat.
Continue reading
Manage All Assumptions as Risks
Assuming something means taking it for granted. In other words you’ve got a more or less conscious theory (or, less charitably, a guess) that something is going to happen. The trouble is that the assumption might not be true.
That screams risk. And as a programme manager or project manager you need to manage risk.
Continue reading
Agile Programme Roles and Responsibilities
To go with my typical programme organisation I thought I’d describe the roles and responsibilities I expect on an Agile programme. Remember I’m interested in software delivery so I’m talking about programmes that have software development at the core. Non-software programmes would have a different mix of roles.
Some roles in an programme correspond to the roles in an project. The scale of responsibility is larger and emphasis on coordination greater but the nature of the roles is broadly similar. The Agile Programme Manager, Programme Product Owner and Technical Architect roles fit this mould, corresponding to Agile Project Manager, Product Owner and Technical Lead.
In addition a programme needs some roles that don’t appear at all in a project, in particular Programme Director and Business Change Manager. Again these roles are a result of the wider remit and increased communication necessary in a programme but also because of the focus on organisational transformation.
Continue reading