What Would Be Your PM Approach: Glen Alleman

We have another set of answers in what would be your PM approach series. This time opinions from Glen Alleman who runs a great blog called Herding Cats. This should be a must-read for everyone dealing with project management, especially for those boxed in one approach. Glen’s thoughts are very insightful and personally I value much our discussions, no matter whether we agree on subject or not. He has also pretty unique background since much of his work is done on huge projects being delivered for institutions like US Department of Defense.

Here are Glen’s answers. There are three situations. For each the question is the same – what would be your project management approach?

You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.

Do we have all the necessary resources for increasing the probability of project success? The Prince-2 process depends on the pre-conditions for success being in place. I’d start with a chartering session where the stakeholders are present. ALL the stakeholders in the same room at the same time. Then, using Prince-2, capture the top level business requirements (business capabilities) in a working session. These top level requirements must not be technical in nature, but must be operational and tied to the success of the business. The units of measure of this success must be meaningful to the stakeholders. They must agree on these units and the beneficial outcomes of the project.

Take these requirements (capabilities) and create a requirements management „tree” in some requirements management tools. These „Tier 1” requirements are owned by the business and the stakeholders, since they are not technical.

Following Prince-2 (which I not experienced at) I’d make sure I had a process advisor on the team that could train, support, guide, and advise all the team members on the various activities inside the method.

But as Project Manager, following the method is necessary but not sufficient. I must have the full attention of the customer at least on a weekly basis to confirm we are making physical progress in accordance with the agreed upon „Tier 1” requirements.

As a process I’d focus on driving every development effort through the requirements traceability to the delivered code elements.

You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.

I’d start with the business side of the house and determine what in their view has been the problem in the past. Research shows that requirements management is a fundamental problem from firms like this to the US Government.

The simplest project management methods are based on making visible what „done” looks like, measuring „done” in units meaningful to the stakeholders, and assuring that these measures occur on fine grained boundaries. The first principle is any successful project – beyond defining „done” – is to answer „how long am I willing to wait before I find out I’m late?” This is the basis of ALL good project management methods. From Ron Jefferies XP to NASA and US DoD 5000.02 Integrated Master Planning.

I have direct experience in this scenario at a large (100) US Department of Energy Nuclear Clean Up site IT project. Define what „done” looks like in a „plan of the week.” Hold each team member ruthlessly to meeting the „plan of the week.” On the Thursday prior, assess progress for the week and reset the „plan of the week,” for the next week.

Weed out the low of non performers on the team. Get the 70 down a leaner 50 or so. Partition the project into separate parallel streams with minimal coupling but maximum cohesion. Do this through a small (1-2) architecture team – handpicked by me, but agreed on by the stream leads.

You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.

As the architect of a fault tolerant process control system I have direct experience in this scenario.

Hire the best damn high availability developer I could find, have a clean and testable architecture, get a toolsmith to support us for everything that gets in our way, build an incrementally developing „simulation” platform to validate and verify the code every day. No one leaves the building until our daily build works against that „test platform.” Repeat daily. XP or Scrum like process work well here as long as the customer is on the team, but doesn’t count as one of our 4.

You can find other people answers grouped in what would be your PM approach series.

PMBOK Can Be Agile Too

I was a part of hot but interesting discussion yesterday on agile community meeting. I was trying to show situations where agile doesn’t have to be a perfect solution. On the list of examples there were one-man R&D project like these done in Google and a tiny startup. A point I made was agile methods are too strict for these environments – you don’t need pair programming, daily stand-ups or 2-week sprints there.

Then the whole thing started. People went with argument that it’s not about every single technique which is a part of Scrum or XP. As far as we’re aligned with Agile Manifesto we’re still agile even if don’t follow every practice. And if some values from “the black list” of Manifesto are important for the customer (e.g. documentation) we should put enough focus on that.

At the first moment I got lost a bit. We can switch anything off as far as it does make sense or is forced by the customer and we’re still agile. Well, this actually means we can have pretty much formalism around which, if I remember correctly, was something agile was trying to avoid.

After a while I changed my mind. Hey, it’s me who advise you to take only tools which works for you in specific situation. It’s me who advocates for common sense in project management above following any rulebook. I definitely wouldn’t tell you to blindly follow any methodology.

This approach however means that you can call agile pretty much any methodology out there. As far as your methodology choice is based on reasonable arguments – e.g. the client forcing you to use more formalized or more heavy-weight process you’re still agile. If you skip some practices because you can’t have stand-ups in the team spread geographically and you can’t relocate these people – that’s fine. You’re still agile. If you put much focus on process to align with the rest of your org you can still say how agile you are.

That actually means you can use PMBOK to run your projects and basically be agile. You can have one of more formalized methodologies and be aligned with values of Agile Manifesto at least in these places where it’s under your jurisdiction. Which makes the whole holy war around agile quite irrelevant by the way. If that’s exactly what my adversaries were trying to convince me to I have to admit they succeeded. However I’m not sure if they would go that far even though that’s only interpretation of their arguments. After all I don’t consider myself as agile expert so I have to base on opinions of these who do.

A disclaimer: I do appreciate agile techniques. I believe short cycles are better than long ones. I think that everyday communication within a project is a must. I hope to see my team working with Kanban soon. And hell no, I don’t consider myself as agile-hater although I was probably labeled that way yesterday by a few people.

What Would Be Your PM Approach: Jurgen Appelo

Today we have Jurgen Appelo who briefly says what would be his PM approach in different situations. Jurgen runs a great blog – Noop.nl – which I advise you to subscribe if you haven’t done it already.

There are three situations. For each the question is the same – what would be your project management approach?

You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.

I might start with XP practices, because project management (Prince-2) is already in place, and could be changed (slowly) to be more agile later. But good technical practices would be higher on my list because of complexity of project.

You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.

I would start with Scrum, because that is a relatively easy step to take to bring some structure to an organization.

You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.

I would start with both XP and Scrum at the same time, because when you start from scratch it is easiest to do everything right from the start.

Pretty brief and concrete answers. I hoped to get this type at least once and here they are.

Keep an eye on whole what would be your PM approach series.

What Would Be Your PM Approach: Shawn Futterer

This is the first set of answers for the same three questions I asked several project management experts. These are thoughts of Shawn Futterer who is a director and the main person standing behind the ICPM (International Community for Project Managers) site which is a great place for all of you who look for high-quality PM content and resources.

There are three situations. For each the question is the same – what would be your project management approach?

You work in a big company and are put in charge of big complex project which is about to be started. People in the company are familiar with Prince-2 but time or budget overruns aren’t anything new, although they’re kept at industry average level. A project team is gathered from different teams – they haven’t worked with each other on any project yet.

I would have to say that in the given circumstance, I would use the following tactics:

1. For Team building, I would host a function outside of the workplace to allow the team members to get to know one another on a personal level. This should lend itself to improving team performance, boost morale and generally keep spirits high.

2. For Team Work I would hold more frequent team meetings. Whether in person or virtual the coming together of team members to discuss status, challenges, roadblocks and successes is crucial in creating a cohesive team environment. If the company standard was 1 meeting per week, I would hold 2 until such time as I felt the team was functioning like a well oiled machine.

3. For Schedule overruns, I would first define the critical path and then employ some techniques such as schedule crashing or fast tracking, running any tasks in a concurrent fashion that can be. These are basic PM techniques. A more advanced approach could be something such as this personal practice of mine; when working with consultants, vendors and outsourced partners I like to define contract terms based on performance. Rewards for exceeding goals and penalties for missing deadlines. This assumes the PM has the ability to source and select vendors. This is fine and good to motivate the vendor to exceed goals and meet deadlines, but it does not help a project that’s behind schedule get back on track. For that we need to start with the basics, Crash and Fast Track. In extreme circumstance we might need to reallocate or swap resources from non-critical tasks to those that are behind schedule. We might need to simply work overtime. This may cause us to go over budget though, so we need to be wary of this. We should absolutely review all upcoming tasks for Float and cut where we can.

4. For budget overruns, I would determine if the budgetary overrun is a result of scope creep. In my experience this is often the case. If scope creep is an issue, we need to institute tighter change control policies. This can dramatically impact our project and keep costs down. Next I might look at things like: material costs and determine if they can be reduced. Are we working overtime? If so, can it be cut down? Do I have salaried employees that can put in extra hours in exchange for time off later? Lastly, a best practice is to calculate a budget contingency when you’re first assigned to a project. Every good PM knows he/she should expect the unexpected. It’s never a bad idea to try and negotiate for a contingency fund for just such cases.

5. In the end if we finish over budget or behind schedule, internal processes need to be reviewed. This, again in my experience, is often a cause for concern. Which process can be improved to have a positive impact on our approach to Project Management in general?

You’re hired to clean up the mess in projects in company of 70 people. So far the company struggles to do any project on time or without major problems. Project management is pretty non-existent and software development along with quality assurance is drowned in chaos.

In this circumstance I might employ the following:

1. A company of 70 people does not require a long drawn out methodology for PM. In this smaller company environment, a projectized approach to PM is desirable, in my opinion. We would use a simple 1- or 2-page methodology to address the basics such as project charter, funding approval, quality control and change control and close out. First thing a small company needs to do is determine whether or not they should take on a new project. Some simple ROI and earned value calculations should be performed. Once a project is accepted, the PM is responsible for it in its entirety. Now we are able to institute some basic PM best practices including milestone definition, task management, team selection and resource allocation and performance management.

2. As with any project, some tasks can be run concurrently, while others have start-stop dependencies. When working with software it’s crucial to define task start-stops and hand-offs to downstream programmers.

3. Scope Management is also crucial. Small companies can be more susceptible to scope creep raising from a desire to satisfy their consumer or marketplace. Change control policies need to be defined and tightly tied to the funding approval and scheduling processes. Change scope only if it makes sense. Importantly, make sure the project sponsors approve scope changes. All other items should be addressed as a separate project in a later phase.

You organize a startup of four people, including yourself. The idea you work on however puts pretty strict requirements when it comes to software performance, high availability and quality. The team isn’t going to grow for some time but in a perspective of year you hope to see a dozen people on board.

This is project management 101, in my opinion. I’m not stranger to a start-up with limited resources, a fast paced schedule to get to market, high quality aspirations, tight budget constraints and the list goes on and on... In this scenario, it’s important to create work packages, distribute responsibilities and work load balance. By taking time upfront to define common practices, the start-up saves time and money down the road. Answering questions like “How will we do things?” “Why we will do them that way?” and “What benefits does this method create?” are a good way to start to define yourself in a startup. Create your methodology as a pathway to success.

There is a degree of value in researching and thinking about your business in a systematic way. Planning helps you to think things through thoroughly. Learn to be critical of your own ideas, this should help ensure those that you implement are sound. Collectively as a group we should determine our PM approach. As it relates to software, do we use SCRUM, Agile, Xtreme programming, or something else? We need to define the iterative process and then incorporate that into our methodology.

In this scenario, there are four people in the start up and there will undoubtedly be more than 1 project going on at any given time. I’ve had a degree of success in having each partner act as a traditional Project Manager where each is assigned to lead a project or a phase of a project. This helps with my points above about responsibilities and workload balancing.

These are answers from Shawn. Soon there will be other opinions on the same problems.

I encourage you to keep an eye on whole what would be your PM approach series.

What Would Be Your Project Management Approach

When it comes to decide which project management approach is best I believe there’s no silver bullet. I’d go even further – in any given specific situation there’s no such thing as ideal approach or a single method which would work best.

I have this thought in the back of my head for some time and I decided to find some arguments either for or against this theory. I decided to ask several industry experts and bloggers the same few questions. How they would act in three different situations.

I’ve chosen people with different experience working in different businesses. I’ve done it on purpose. Usually solutions we believe are the best differs basing on our past experience, knowledge and things which worked for us in the past. What more we all are biased in some way, which also influence paths we choose.

Situations I’ve chosen are different too. One is about big project in corporate environment, another is about cleaning the mess in fairly small company and the last one is about setting things up in a startup.

I’ll publish these posts once or twice a week. Below you can find all published so far.

• Shawn Futterer
• Jurgen Appelo
• Glen Alleman