Author: adam

Ten types of Project Plans – Which type is yours?

Plans Project plans and planning are inevitably a part of any project initiative. In almost all enterprise environments projects are next to impossible to initiate and to execute without a plan. By “plan” I mean any artefact that attempts to define the current and future activities and outcomes for a project. I know there are many who don’t support the idea of a forward looking or deterministic plan, but even those who don’t follow “big plan” methodologies recognise there is value in some level of planning. And in fact very few plans at all ever produce the level of certainty that their stakeholders would wish them to provide. This post focuses more on the communicative and predictive purposes which attempt to answer the questions: “is the project going to complete on time?” and “how do we know what is going to happen?” Regardless of any “standards”, e.g. from a PMO, that might dictate the ideal form and function of a plan, the actual plans that are used day-to-day evolve pragmatically around local stakeholder drivers and influences and are often the lowest common denominator of all inputs that the project can get away with. Very few plans ever get to the stage where they “lead” the project and can be put to use as predictors of the future or can drive discussions about what might need to be done differently...

Read More

You know the team is too large when…

If you’re a startup, then your organisation is the team. If you’re in a larger enterprise, your team can start small: maybe even just with you! but if you are even modestly successful, you’re going to have to grow the team. In fact, beyond the craziness of early stage startups, mostly you have to grow the team in order to be successful. But as you grow, you run the risk of getting too large. How large is too large?

Read More

“That’s Not Agile!”

We implemented all the relevant principles in the Agile Manifesto, and serviced the Manifesto values. We didn’t contravene or ignore anything defined in the manifesto. Even more, it was proving itself in the early stages: the team bound together quickly just through the discussion and planning on how we were going to do it. We had designed a nice mini agile methodology but the development department wouldn’t play ball: they said “that’s not agile!”

Read More

Thanksgiving for IT Teams: Lock in your team’s achievements!

Scrum and Agile Guru Mike Cohn wrote in his weekly Agile Tips email that we should mark the moment to focus on what our teams have achieved. Triggered by the bigtime Thanksgiving celebration in the USofA, Mike wrote how we often struggle to recognise the past good work done because we are focused on how much we can improve in the future.  He said: “There are literally hundreds of ways in which a team may have improved. Find a few and then share the good news with the team. Praise them. Thank them.” — Mike Cohn (Btw, you can subscribe to Mike Cohn’s emails here) The most important by-product of this is to make the achievements concrete. It would be great to make them persistent, but I’d settle for short-lived crystallisation into the real world. Why? Because it’s so easy for teams to forget their achievements and to gloss over their successes. In fact, the better the team, and the more outcome-focused the team is, the less they seem to celebrate; except perhaps some wry or sarcastic comments, a few obvious high-five’s and maybe an ‘Attitude Adjustment’ session at a pub. But this tends to disappear quickly and all that’s left is maybe a sore head and an expense claim to file. It’s as if the really good teams just have a higher standard of what is “superlative achievement”, or they...

Read More

Subscribe to AdamOnProjects

Never miss out on anything.

Pin It on Pinterest