Tag: Project Management

Breaking projects into tasks

I was been feeling a bit unmotivated at work a while back until I realized one reason why. I took (yet another) look at my task list and found most of the remaining items were not tasks, but projects. They were projects that would take multiple hours to complete and in many cases weren’t clearly defined as to their final results. What were these projects supposed to produce? How would I know when they were done? How would I start them? No wonder I didn’t feel motivated. People don’t do projects; they do tasks. When I looked at this task list I saw vague, undefined projects that had no defined end and no defined place to start. They represented hours of work when I rarely have consecutive hours I can spend in one place to work on one project.

So, I picked an item of my list and asked myself what I needed to do to start on it. In this particular case, the answer was to locate an old version of a similar document I had to write, take a look at it, and decide how I wanted to change it for the new document I had to write this time.

A colleague and I regularly teach this trick in a task management class we lead, and it’s standard course in any Getting Things Done like approach: always start and stop a project by noting your next task. Doing so always gives you a concrete place to start when you pick the project up. I shouldn’t have had to remind myself to do this, but at least I’m glad I eventually remembered. A good reminder for myself, but also good to keep in mind when people you work with are not making the progress you expect. Maybe they don’t know where they are headed or maybe they don’t know how to get started. There are both easy things to fix once you are aware of what to look for.

18 October 15
Some thoughts about commitments

No, this Blog is not dead. I think about it often; I just don’t have as much time as before to update it. I started taking some remote classes (what was I thinking?) and they are pretty much devouring every spare second I have, so this blog, along with most of the rest of my life, suffers.

I am learning lots of neat new things that apply to astronomy management, though, and I am anxious to get them up here eventually. One concept I am pondering now is the use of hard commitments in astronomy. In the real world, a hard commitment is used to signal your intentions to competitors. It is designed to get them to act on your intentions and as a result, it is characterized by three things: visibility, understandability and irreversibility. For example, if you make a press release saying you are going to expand production, that is visible and understandable, but fairly easily reversed. On the other hand, if you invite the press to witness the unveiling of your new $26M factory, that adds a level of irreversibility to your signalled intention. Your competitors are going to have take your increased capacity into account when they plan their strategies.

There are lots of applications of this concept in astronomy management. For example, if a manager asks you to join a new working group to address issue X, or join the team of project Y, you may be wondering if it will be worth your while to do so. Will your eventual solution to issue X ever get listened to and implemented? Will project Y ever really happen? What if, instead, that manager told you that project Z was killed so that project Y could get have the resources it needed to succeed, or that the chair of the new working group is a new employee whose full time duty is to solve issues like this? Wouldn’t you be a little more convinced that your time would be well-spent? Showing real, hard to reverse signs of commitment to a project helps others commit to it as well.

You can apply this concept as well to claim scientific capability ground in telescope operations and instrumentation. I still think we should be cooperating more with each other, in general, but there are also appropriate occasions to clearly signal your intentions if you want to make something actually happen on a desired timescale. A hard commitment is one way to do so.

Stick around, and I may some day write about how a hard commitment helped make a dream happen at our observatory.

10 October 12
Resource Management: Focus on the workers, not the managers.

Inspired by the Norm Smith talk I recently heard (see previous post), I purchased his book Got Progress? and highly recommend it. I now have words to describe some of the unease I’ve been feeling about my workplace’s current project management and resource allocation approaches.

The brightest light bulb went off when Norm bold-faced (and I’m paraphrasing): Build project management structures for the people doing the work, not management. In particular, Norm revealed that he rarely found a resource-loaded project plan very useful and integrated master plans even less so. Why? Part of the reason, is these things are usually done for management, not for team members.

Where I work, we spent a lot of time developing a system to let management know if we have enough resources to do the projects we want to do. We’ve evolved from rough estimates to complicated spreadsheets to an online project task and resource tracking tool to a interwoven combination of all these tools. We have reports that go from project managers to a resource review committee to upper management. In short, we have a very complicated system that ensures resource estimates and allocations are properly conveyed from project mangers to upper management. The problem is, the average employee would agree with Norm Smith in saying it’s great the management knows (or at least, thinks they know) where resources are allocated, but wouldn’t it be nice if the project team members (also called Project Implementation Specialists, in PMBOK speak, I just recently discovered) also knew where they were allocated?

We’ve built a very details system of resource tracking mechanisms for management, not for project members. We have tools that tell management that every staff member is fully allocated to the necessary projects, yet when I talked to several random project members recently, they admitted to not knowing everything they are supposed to be doing. Clearly, the complex system derived to let management know that everyone is properly allocated to the projects to which they should be allocated, is failing to make the resources themselves aware of what’s expected of them.

Crazy idea: develop the system so that project members each have a clear understanding of what their tasks are and let over-allocated resources (conflicts) rise from below. If employee-X knows what tasks are expected of him and doesn’t have a problem getting everything done on time, what more does management need? Similarly, if employee-Y realizes she can’t do all of her project work on the schedule required, she can raise her concern upstream without complicated structures and calculations put in place to detail her exact level of loading.

Our goal is to get the work done. It does no good for management to look at an integrated master plan and see that everyone is assigned the right percentage of time for the right tasks if the employees themselves don’t know what’s expected of them. Build a system that makes it clear what is expected of them (and that system would ideally be tailored to the individual, team, and particular project), and you have a system that has buy-in, accountability, and self-policing. If the work is getting done and conflicts are identified and highlighted by those doing the work, management can focus on only the conflicts that arise, and the project implementation specialists can concentrate on getting their projects implemented!

Speaking of project implementation specialists, Scot found Norm Smith’s book so useful partially because it clearly represented real-world experience with project management. Textbook project management, like the PMBOK, for example, provides a fine framework for project management, but needs to be implemented while taking account of real project complexities and not treating each project as if were the ideal project. Like the frictionless pulley, Scot suspects the idealized PMBOK project doesn’t exist.

22 May 12
Additional Random Bits from the NASA PM Challenge, 2012
The annual NASA PM Challenge is a really good meeting. The speakers are generally excellent and the material covers a wide range from project management fundamentals to the latest great and innovative management ideas. The ratio of outstanding talks to duds is excellent at this conference. Following up on my last post about Norm Smith’s talk at this meeting, here are some additional random ideas, lessons, and thoughts I noted from various talks at the conference:
- Be wary of SPI: it does not care if the work performed was on critical path or non-critical path items. Your project may be more or less on track than SPI indicates.
- For typical projects, CPI does not change significantly after 20-30% of project completion. If the CPI is not good at that point, significant intervention is likely needed to correct it.
- Good PM risk reduction technique: ask “If I gave you some $, what risks could you reduce for how much?”
- Listen to learn.
- Think “I get to” vs. “I have to”.
- Contracts need to acknowledge and provide for iterative and collaborative risk management.
- Contracts should support and provide for strategic as well as tactical collaboration.
- How many technical innovations from the past 20 years do you use daily? How many management innovations from the past 20 years do you use daily?
- Sometimes you have to cast away past successes to reach new ones.
- No one comes to work wanting to do a bad job.
- Adapt to your team, not v/v.
- Starting a new online platform? Seed it with content before going live. People won’t come back if there’s no point the first (few) visit(s).
- Take your job seriously; don’t take yourself seriously.
30 March 12
Managing Cost, Schedule, and Scope is not enough.
Project Management 101 teaches the need to actively, and simultaneously, monitor and manage a project’s cost, schedule, and scope. Project Management 102 might add risk management to the list as well. These ideas have become fundamental tenets of project management and have been around for decades, yet projects still fail. Are project managers simply not learning these lessons and not actively managing this crucial project management trinity? Or, perhaps, is there something more that’s needed?

I certainly agree that a project must manage its cost, schedule and scope. I’ve even written about the importance of doing so, but this alone, as countless delayed, over-budget, and failed project have told us, is not enough to ensure project success. A project must first be addressing the right issue. Is the result of the project what is needed? A project also needs a project sponsor who can provide support when needed and work internal and external stakeholders to develop a consensus for and enthusiasm about the project. Additionally, a project needs overall stakeholder involvement and buy-in. And finally, a project needs good change management. Change will happen; it’s how it is handled that can make or break a project. Without properly addressing these items – project purpose, sponsor and stakeholder involvement, and change management – even proper managing of cost, schedule, scope and risk will likely still result in a failed project.

Norm Smith, in a recent talk I attended, (you can read more about Norm Smith and his ideas at his website: http://www.smithops.com/Training.php; I definitely recommend watching Norm’s brief video via that link), broke this list down (and improved it) as:
- Situational Awareness
- Enfranchisement
- Boundary Maintenance
Situational Awareness is understanding where you are in the project, where you started, and where you are going. Schedules and project plans are often the tool used to create this awareness, but they don’t always work for that purpose and they are often used more as a means to themselves, and not as a tool designed solely for situational awareness. Norm stressed the importance of using a schedule to the detail needed to provide the right amount of situational awareness. You don’t always need each work package broken into half-day tasks to successfully manage a project and maintain situational awareness.

Enfranchisement is fairly simple – getting your team and stakeholders (including the project sponsor, which I had separated out, above) united in the project mission. This task is crucial if you are to efficiently deliver the right products and overcome unexpected surprises thrown at you along the way.

Boundary maintenance is akin to scope management and change control. It is making sure the project does what it is supposed to do, not more, not less. It is also responding appropriately to the change which is inevitable for most projects.

In this new light, managing cost (ex., Earned Value Accounting), schedule (ex. Work Breakdown Structures, Microsoft Project), and scope are simply tools used to create the situational awareness and boundary maintenance that are the real core components necessary for a successful project. Don’t let these tools control the project. They are not the essential tools for a successful project; they are simply tools, and not the only ones available at that, that may help you create the real elements needed for project success.

If you’re interested in project management, especially as it pertains to large projects, Scot highly recommends the annual NASA Project Management Challenge meetings. Some of the best talks he’s ever heard have been at these meetings.
26 March 12
On systems, processes, and paperwork
Lately, I’ve come across several proposed new systems, processes, and forms — all developed to address an assumed real, but unstated need. In most cases, I could see a useful purpose for the new system/process/form, but it usually wasn’t provided to me explicitly. I didn’t know if my interpretation of what this new proposal was all about was shared by those directing it so I often feared I would be wasting my time by doing something that wasn’t what was actually wanted.

Developing a common framework and tools for management tasks makes sense, but there must be a system behind them, else you just end up creating a bureaucracy instead of an effective, efficient system. I see several things to address before implementing a new system, process, or form:
1. What is the purpose/goal? What problem are you trying to solve?
2. Who is your audience?
3. What are the requirements needed to fulfill your objectives within your target audience?
4. What are the implementation costs?
5. What are the costs of non-implementation?
6. Given all the above, is implementation the right approach?
There’s nothing terribly new here, but the items above make a good checklist to go through before starting a new formal process. If you don’t address the first three points, you may end up spending a lot of time doing something which propels you no further down the road. In addition, if you don’t evaluate the costs of what you’re proposing against the current incurred costs in light of your available resources, you risk spending too much time on something that is ultimately not going to improve your situation enough to be worth it.

Large projects need a fairly broad framework in which to operate. They also, typically, staff a project office sufficiently to help produce and support this framework. While smaller projects can also benefit from this same framework, typically the cost of doing so is prohibitively high. So, smaller projects must think carefully about what it can do, what it can’t afford not to do, and ignore the things it can afford to not do. Going through a similar checklist as above ought to help decide into which category a proposed new system belongs. (Actually, I’m sure this same approach works for large projects as well — we are all resource-starved these days.)

Speaking of checklists, Scot found the book “The Checklist Manifesto” by Atul Gawande a very good read and a great strategy for helping to ensure routine tasks are done correctly every time. Packing for trips, as an example, got immensely easier once checklists got involved.
21 December 11
“I set early deadlines so people work hard to get done as soon as possible.”

I recently heard a project manager say something like, “I set an optimistic, aggressive schedule to make sure people work hard to meet the deadlines, otherwise, they might back off and not work as hard as they can to finish on time.” What she was trying to say, in other words, was that she believes setting an unrealistic schedule will motivate people to work hard to finish their tasks as soon as possible. What I think setting an unrealistic schedule does is teach people that your deadlines are meaningless. It therefore only motivates them to pay no attention to your schedules at all. I suppose this manager’s approach might work once, but it certainly is not going to work for long.

Would you rather work for someone who thinks she can trick you into working hard by setting unreachable deadlines, or one who involves you in coming up with a reasonable schedule and then gives you the tools you need to help you finish on time?

23 February 11
Working with academic vendors…

In my previous post, I made the outlandish statement that not all vendors are well-versed in the skills needed to properly handle large, fixed-price, contracts for one-off products.   Now, I want to discuss some ways to effectively work with such contractees.

Risk: Many vendors feel they are simply not prepared to assume the risk that’s involved in a fixed-price contract. When you press them, of course, you find that risk assumption is not the real problem. If you ask questions like, Could you do the project for $10 million? Could you do the project for $100 million. What if we offered you $1 billion? These questions are obviously silly, but they illustrate the point that there usually is a price point where the risk can be assumed. So, what they usually mean by we can’t do a fixed price contract is that they don’t understand the risk well enough to be able to price it into their bid. With this insight realized, there are a number of approaches you can take:

1) accept certain risks for the vendor
2) initiate some pilot studies to assess and/or eliminate key areas of risk
3) allow some flexibility in the bid price, with certain elements being priced only after enough effort has been made to understand and costs the risky bits
4) simply encourage them to price the uncertainty into their bid and submit a higher priced bid

Working Relationship: Most academic teams don’t really like the customer/vendor relationship model. Many of them are in academia, and not industry, for exactly reasons like this. They usually prefer a more interactive partnership where science objectives, technical requirements, and management decisions are made more jointly with less clear lines of authority from contractor to contractee. The goals of the academic world include building and sharing new knowledge and closer interaction with the project partners helps fulfil these objectives.   The contractor, therefore, has to be willing and able to devote more resources to the project and have more interactions with the contractee than they might otherwise have, sometimes partnering in parts of the work and mangement efforts. Lines of ultimate authority and responsibility can get a bit blurred in these situations, though, so it is important to make it clear who has the final say when necessary (although only when necessary) and what decisions and discussions have contractual implications vs. those that are simply exploratory debates and discussions.

Understanding the Contract: Many of our vendors (academic or not) do not seem to fully read or understand our contracts. They often do not know exactly what they are expected to do, nor what their rights and responsibilities are with respect to the contract. Sometimes this lack of understanding actually helps the contractor when, for example, a contractee does not realize that a change initiated by the contractor does not have to be accepted without additional compensation. But even in these cases, ultimate harm is done to both the contractor and contractee if the contract terms are not openly discussed and enforced by both parties. No one who loses money in a contract due to changes by the customer will want to contract with them again, for example. So, it is vital for the contractor to really explain the contract to the contractee and to constantly refer to it and abide by it when new situations arise. This behavior gets everyone’s rights and responsibilities out in the open, eliminates a lot of arguments about what the correct course of action is, and build good relationships for this and future work together.

Contingency Management: I referred to this issue in my last post, but it’s of such vital importance to the success of a project that I want to bring it up again here. First of all, it is important to realize there are three types of contingency: cost, schedule, and functional. The temptation, typically, is to use them in that order, but that is exactly the wrong thing to do.   Towards the end stages of a project, often when the most problems occur as the pieces come together for full assembly and integration, there is very little functional contingency left. The only thing that will get you our of a jam at this point, is usually money. The only time functional contingency has any availability is early on in the project, before the design has been set and components purchased. Unfortunately, early on in the project, there should also be lots of cost and schedule contingency, so the temptation is to keep the product fully functional and start dipping into the cost and schedule buckets. The problem then comes, of course, at the end stage, when the functional contingency has expired and the cost and schedule contingencies have already been spent. You don’t want to hoard your cost and schedule contingencies past the end of the project, but you do want to make sure they are available in the latter stages of the project when you are most likely to need them.

The scientists and technologists involved in a project will not want to give up functions early in the project when, from their point of view, there is a pile of available time and money just waiting to be spent. Worse still, they may want to start adding features as new ideas and products are discovered that will enhance the end product. Ask any experienced project manager and they will tell you that succumbing to these two temptations is to go down a very precarious path towards successful project completion. So, one technique to employ is to leave hooks in the project for the cut or new functionality and set a date by which time it can be included if other risks have not been realized. Doing so establishes the mindset that these three areas of cost, schedule, and function have to be continually balanced within each of their finite limits and may even inspire people to work harder in other aspects of the project so that their favorite functionality can be restored/added later.

5 December 10