The Regenerate Web

Project Management means different things to different people. From the social and humanistic aspects of managing the people working on and around projects, to the gritty details of a Performance Measurement Baseline, with in integrated cost, schedule, risk, and technical performance measures.

One advantage of working the in Space and Defense business is the social and personality aspects are minimized. Not gone all together, but certainly much less than commercial domains, where egos get in the way many times of getting things done. In A&D "done" is clear and concise - the machine flys away, the product does it's job as defined in the SOW, with measurable outcomes, soldiers are using the product, things like that. Black and White, either it flys or it doesn't fly. Of course it's not that simple, it never is.

But one thing that is different in A&D is the focus on the processes and tools. I'm working a moderate ($300M) Army program through January when we get to the Integrated Baseline Review (IBR). While poking around looking for some ideas for training our customer, I came across PM Lotus's "Setting Baselines in Microsoft Project."

The Baseline is just what it says it is, the "baseline" of the cost, schedule, and technical performance. Now MSFT Project is not the best at managing baselines. In fact it's pretty poor at managing baselines. No change control, no traceability, not much in the way of mandated documentation. But it's popular and most of our programs use MSFT Project.

Drill down into this site, there are some very good articles for those interested in the programmatic aspects of project management. Like Checklists.

I woke up from a dream early this morning. In the dream I was trying to move through a crowd at a conference but I could only move in slow motion - like I was walking in thick mud or with heavy weights on my ankles. I was frantically trying to go fast because I left my conference tickets back at my office.Time was ticking and the start of the conference was 40 then 30 then 20 minutes away. I could not miss the start! And when I tried to use my cell phone to call someone to help, I could not find them or the number was wrong.

As I reflected on this dream (interestingly I have had a similar dream before, have you?) the following pairing of phrases popped into my mind:

• Sense of urgency
• Inaction

That is what it felt like - like trying real hard and not going anywhere. Obstacles popped up everywhere. Do you have days like this? When we do, perhaps the place to look to get going again is not in the action, but in the focus - maybe the sense of urgency is poorly defined or not the right focus. 

Trying harder might be the solution sometimes, but I would bet the answer often lies in how we focus and tune our intentions.

Let's not waste time frantically going nowhere.....Is this what the dream is telling me? Who knows! Seems like sound advice!

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

Next Monday is Labor Day in the US. And I wonder, why do people work? Elliott Jaques is very specific in his response.

“People want work in which they can have the opportunity to exercise their full potential capability, to spread their wings widely, to receive a fair compensation for that work and to be recognized and understood as not needing artificial carrot and stick treatment on order to get on with that work.

By work, I mean an organism’s use of judgment in making the decisions necessary to reach a goal. Goal directed work is a basic feature of all life.

All humans need to do work that not only benefits oneself, but is, at the same time, of value to others.

It may be noted that, not only do millions gain work opportunities by becoming engaged in employment, but need something on the order of 40 hours per week of such engagement. That is what explains the fact that the employment work week, which came down to 40 hours during the first half of the twentieth century, has gone no lower. Any smaller number of hours is not sufficiently fulfilling. Indeed, people who work on their own, routinely spend many more than 40 hours per week.”

Elliott Jaques – Social Power and the CEO

 I was having lunch with friends the other day, and they started asking my advice on some chronically bad behavior at their company.  They were complaining that dysfunctionality was running rampant in their organization, and were wondering what they could do about it.

I asked them one simple question:  "How do your executives act?"

The response was as I expected.  Terms such as "childish" and "distrustful" and "conniving" were thrown about.  It was simple cause-and-effect.  The employees misbehave BECAUSE the executives misbehave.  A while back, I was asked to respond to a letter on Office-Politics.com where the top three executives were having affairs.  I suggested to the letter writer that he may want to consider a career change because their behaviors would eventually filter throughout the company.

It's pretty easy if one person misbehaves.  In school or at daycare or at home, you have a time-out chair to help correct the errant child.  (Some children spend more time on the chair than anywhere else.)  However, a couple of centuries ago, Britain decided they needed a whole island to deal with their less-than-stellar citizens, so Australia was colonized as a prison.  (Now people vacation there; go figure.)  So it is with some organizations.  If you have one or two bad employees, it's fairly easy to deal with them the traditional ways: coaching, counseling, corrective action.  If the whole lot are acting like a werewolf convention during a full-moon, then you have a problem with the overall culture.

The diagnosis of the systems output is simple.  However, the cure can be more challenging (but not impossible).  If enough people (namely executives), decide they want to change the culture (think Seattle's world famous fish market), then anything is possible.  With the Fish! example, the decision to change had to come from the top man himself, and then he had to make good by modeling the behaviors he wanted to see.

Where do you see yourself fitting into this organization?  Are you prepared to tackle an entire culture?  Some battles you can win, but some wars are costly.

There are no easy answers, but it certainly gives you something to think about if you're in an organization where you dread getting up in the morning.

We’ve been opening new Stack Exchanges left and right on a variety of topics. In almost every case, the Stack Exchange appears to duplicate the content of an existing community. For example, our WordPress answers site (now in beta) covers the exact same material as WordPress.org’s existing forums.

This is nothing new to us at Stack Overflow, which purported to cover the exact same material as hundreds (if not thousands) of other programming sites. There’s no rule that says that there needs to be exactly one Q&A website per topic.

There is, however, a compelling case for the Stack Exchange technology. WordPress.org’s forums don’t have voting, so you have to read through every answer and decide for yourself which one might solve your problem. They don’t have reputation, so there’s no way to see whether you’re getting an answer from someone who knows what they’re talking about. They don’t have wiki-style editing, so collaboration is impossible. You have to log on to ask or answer a question, so the burden of participation is higher. Stack Overflow is simply better than traditional forums, which is why it largely replaced proprietary forums. I remember hours of discussion with John Resig and the folks at jQuery who couldn’t decide whether to replace the jQuery Google Group with a forum or with a Stack Exchange. Ultimately it didn’t matter that much, because most of the jQuery Q&A activity happens on Stack Overflow anyway.

One day, the features that are standard on Stack Exchange will be copied everywhere. Until then, we’ll keep churning out new sites.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

Some teams don’t do demos at the end of their iterations. Many of the teams who don’t do demos also have trouble finishing all the stories they committed to at the beginning of the iteration. They continue, iteration to iteration, not always finishing, not getting to releaseable at the end of the iteration. And, sometimes, these teams don’t do retrospectives because they are not done.

There’s significant value in a demo at the end of the iteration.

1. The demo shows the team what they have done and not done in the iteration.
2. The demo shows the product owner/customer what they have done and not done.
3. The demo acts a a milestone–the team has to stop what they are doing to show the demo. They can’t keep going without doing a demo.

If you’re not demoing at the end of an iteration, reconsider. Use the demo to get feedback, record your velocity, and see if you are done enough with this project for now, or if you really need to continue working off this backlog.

Tweet This Post

Fascinating article by Forrest Christian on the role of trust required for an organization to deal with uncertainty. As you read the article, you may think about how this operates in your own organization. Stepping back, you may see more clearly the dysfunction in the current US operating government by its lack of trust.

Forrest Christian – Trust is Necessary

Wally Bock, pal, fellow blogger, writer, and management expert, sent me a copy of his new book called, Ruthless Focus: How to use key core strategies to grow your business (Wally partnered with Thomas Hall on the book). And I would like to recommend this book for all leaders and managers.

Knowing that Wally had worked on the book, I expected it to be honest and direct, even when the message is one you might not want to hear. I expected conclusions to be insightful and insanely helpful, because that is how Wally delivers his messages.

And the book did not disappoint. Ruthless Focus is an important book because it addresses a topic that we don't talk about enough - focus versus multiple or changing #1 priorities. Actually, we talk about it often but not in the way that is helpful. This topic determines how we create a good plan and follow-through. In our "shiny object" business culture, sticking to a plan is often laughed off as unrealistic and not an option.

Here's the bottom line - you can ignore this topic, but it might be at your business's peril. 

Thomas and Wally researched successful companies and unsuccessful ones, and companies that were successful for a while and then withered. They share their findings in the book, which are provocative (not in a "gosh, I am shocked" way but in a "kick me in the butt I need to pay attention" way). They tell great stories about real companies we all know and some love.

The authors did not say this in the book, but it strikes me that the overall manta of their suggestions could be, "create enduring success through focus and discipline that enables engagement and excellence." This may not be as sexy as frequently reinventing the strategic plan but it is what will help your organization succeed, respond, and grow over the long haul.

For those of you who are frustrated by strategies du jour and revolving leadership styles and missions, you might want to get a copy of this book for your leadership team and facilitate a book club brown bag session. Let it catalyze great conversation and affect your thinking and future decisions.

Any manager or leader who reads this book will be better able to plan, measure success, and follow-through on core strategies. If they follow Wally and Thomas' advice, they will be able to achieve focus that opens doors to greater performance, engagement, and creativity.

There you go. Buy it. Read it. Be it. Pick up Ruthless Focus here. Excellent work, Wally!

In my previous post, I invited us all to have our best day ever and best week ever and offered a few suggestion for how to do this. I wanted to explore one aspect of how we experience our work a bit deeper.

Task completion versus task mastery. Is there a difference? Huge difference!

Task completion means you can check off the box. Been there. Done that. You might even have very detailed goals that make sure that you complete the task or project at a high level of performance. Success is usually defined by someone else, or a departmental plan, or an internal or external customer.

Task mastery occurs when we become in the "flow" with our work and perform in ways that can't all be measured. There is the task completion and quality that can be measured and then there is that je ne sais quoi (translated: I do not know what) or something special.

Your something special, your flow, your mastery, will be different than mine. We each have a special eye and a unique filter and a one-of-a-kind ability and when we bring this forth in our work it makes a huge difference.

So as you launch forward into the new week, take the time and care to bring your best to even the seemingly tiniest tasks. Do you have a staff meeting coming up? Don't show up checked out and automatic, enter the meeting room like you would have on your first day of work - interested, engaged, and ready to share your best thinking, listening, and partnership. Regardless of how many crappy meetings you might have been through in the past, see the next one as a huge opportunity and privilege. The moment you stop believing is the moment when mastery will no longer be possible.

You might retort: But what if I don't care about the depth of my performance at staff meetings?

My retort: This is not about giving something to your boss, mastery is for you. When we are in the zone of high performance, we enjoy our work more fully and we feel more successful. 

You might retort: Well, I will save that for something I am interested in, like project XYZ.

My retort: If you are present and in the zone during even small tasks, you will have much more capacity and focus to bring to the project. If you choose to check out and be automatic much of the time, you will experience more stress, distraction, and your brain will reinforce negative patterns.

I invite you to experience each task with a heightened sense of connection and focus - and make this the best week ever.

If you would like to join our little online group aimed at making this and every week the best week ever, read the previous post and drop me an email.

“The economic news is disturbing,” Morgan explained.

I nodded in agreement. “So, what are the actual impacts to your business and your market? The world is not ending, it is shifting. You think you are dancing on bullets. You have to find the rhythm in the dance.”

“I know, I know,” Morgan shook his head. “But, this recession has lasted so long. My people are tired. My customers are tired.”

“Then stop whining and figure it out. Get rid of the long face. Search for your advantage. Your competitors are suffering, just like you. In this market, in the midst of this chaos, there is opportunity. New undercurrents will surface. Are you watching them?”

I came across (actually Pat Richards alerted me) to an article about how Earned Value is not applicable for Software Development project. This article was in a PMI IS SIG news letter. See Pat's post. You can retrieve the article by following the link on Pat's Blog.

Here's the core of the concept proffered by a PMI Special Interest Group on Information Systems.

It is very difficult to accurately and objectively measure the progress in designing and developing software.

My first response was "really?" The very essence of project management is to apply some measure of progress to plan. Simply showing up and putting in 40 hours a week is a measure of progress to plan for a Level of Effort task like watching the trains pass the crossing. (They used to have a job like that in the old Federal Republic of Germany when I was there in the mid 70's detoxing from a tour in Vietnam).

Also the very essence of Scrum - or most agile development processes - is to produce planned measurable outcomes from the work effort. All agile methods MANDATE the production of working software. How to define what software to "get working" varies by method, but Scrum connects the work efforts with the "requirements" through a Feature and Story list developed by the stakeholder.

Software projects also have the problem of iterative development approaches in which certain activities often must be revisited a number of times before they can even be considered completed.

Yes this is true. This is true of every project on the planet. It's part of life cycle of projects. From the extreme approaches of XP to DoD 5000.02's procurement cycle, incremental and iterative approaches are used.

This is not a "problem," it is a fact. Apply the appropriate method to deal with this.

And then the final stroke is "really bad project management"

Many of the activities in software development projects more difficult to measure accurately and objectively in order to compute the actual earned value of the work accomplishments. It is very difficult to accurately and objectively measure the progress in designing and developing software. Often the project manager must simply accept the developer’s word for how they are progressing rather than use an objective measurement. For example, when is developing a computer program 25% or 50% or 90% complete? We can measure the cost of the developer’s efforts but not the needed corresponding progress toward completion.

Please tell me this is not the approach being blamed for software project failures. Better yet please tell me that Earned Value cannot be applied to software development because of these types of projects.

Earned Value is successfully used in a variety of software domains - Enterprise ERP, defense and space system, which are all software intensive, embedded control systems.

Core Success Critieria for Earned Value and Software Development

• Define the outcomes of the work effort in some tangible way. Physical evidence is best. 100% working code (at least for the planned deliverable) is best of software. Tangible evidence for other things is just that - evidence that work produced the "thing" that was planned to be produced on or near the day (or week or month) it was planned to be produced for something close to the cost that was planned.
• Define the way progress is going to be measured. 0/100% of the work. Either it's do or it's not done. Other measures of progress can be 50/50 (half when you start, half when you show up with completed product), apportioned milestones. But NEVER EVER is progress measured by asking someone "how far along are you  on the software module you are working on?" The answer can NEVER EVER be "well, I've been working real hard and I think I'm making progress, so let's say I'm about half way there with half to go."
• Define the tangible evidence, the date the tangible evidence is expected, and the associated costs.
• With this you've got all you need to do EV on Software Projects. Ignore completely the suggestion in the IS-SIG article, that EV and SW Dev don't mix. It's done every day on billions of dollars of software development.

There are many discussions around what works and what doesn't work in the management of projects. Words like:

• Earned Value can't work for our problem. I've seen it fail, so it can't work.
• Agile is nonsense, it's not right for our domain.
• Requirements must emerge from the development of software, you can't possibly define what the system will do up front.
• I've taught 100's of project managers how to implement PMBOK® so I must be capable of managing real projects, no matter the domain.
• And endless other anecdotal examples of how a person with an opinion generalizes that opinion to the universe of problems.

Here's a suggestion. One that I've observed over the years. Those years having started in the late 70's when managing software development was an engineering role and having landed in the defense system program management world these days with formal probabilistic models of performance for billion $ programs.

Here's my suggestion. There are 5 IMMUTABLE principles of Project Management. These immutable principles keep coming up every time I hear someone speak about the problems they are having with a concept. The previous post was a trigger to restate these principles.

Five Immutable Principles

If you're going to successfully manage a project you must ask and answer these five questions. If you don't have credible answers for these five questions, do not proceed as a project manager. Stop, get the answers. Insist the stakeholder provide answers. Without credible answers, the project's probability of success is lowered. Possibly lowered to the point of assured failure.

The five immutable principles of project management are:

1. Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now.
2. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan.
3. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable.
4. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.
5. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.

In the absence of credible answers to these principles, you can come up with all kinds of reasons why things (methods, tools, processes) won't work. In fact you can come up with almost any reasons as to why projects fail.

Answering this principles in some credible manner doesn't assure success. But it goes a long way to improving the probability of success.

If you can't afford to mitigate the risk now, be absolutely sure you can afford to resolve the problem later when it happens.

- Introduction to Universal Risk Report, The Risk Management Research and Development Program, INCOSE Risk Management Working Group.