Some+thoughts+about+Feb+2

I've really like Linda's summaries and reflections on the classes so far. It helps me to think about what I walked away understanding.

Last night's class was eye opening for me. Linda's anecdotes reinforced for me that systems development practices parallel instructional design. However, I could also begin to see the differences between these efforts. I was impressed to hear how as an Instructional Designer, Linda was able to very quickly assess why the PowerCom software had problems. Very cool. The other example that I had not considered was from Suzan (sp?) regarding the Denver Children's Museum, and how she recognized right off the bat that the exhibits did not have an instructional design strategy to them. Again, very cool.

I teach a course on Project Management, and I developed a presentation that was based on Edward Yourdon's book, Death March. I included the script I prepared for the presentation after Ed Yourdon's quote. You may not want to read it all - it's lengthy, but it does give you a quick overview of the Death March by Yourdon. I strongly recommend the book because it is instructive and entertaining.

“Having worked in the software industry for over 30 years, I find that our profession has a rather interesting reaction to Death March projects. In some parts of the industry, especially in Silicon Valley, such projects are glorified as a test of fortitude, somewhat akin to climbing Mount Everest barefoot. I felt this way during my first few software projects back in the mid-1960’s, and the fact that the same attitude prevails a generation later suggests to me that it’s likely to be a permanent phenomenon, as long as technology continues to change as rapidly as it has been during my lifetime. Ours is not a mature industry. Every year there’s a new Mount Everest to climb and a new crop of hotshot programmers who are convinced they can run barefoot all the way to the top.” //Edward Yourdon//, **The Death March,** 1997

Up until now, we have investigated the Project Life Cycle and the tools and techniques designed to manage a project effectively. But what happens when things go wrong? Will all of these tools and techniques eliminate failure? Since a project is uncertain, so too, is the outcome. Let’s turn our attention to situations that require flexibility and the knowledge to deviate from standard project management practices. Much of this lecture is adapted from Edward Yourdon’s book __Death March 2nd ed.__, 2004 published by Pearson Education.

Many projects feel like a Death March, but for them to meet Edward Yourdon’s definition, they need to fall into one of the following categories.
 * – Schedule compressed to less than half the amount estimated by a rational process
 * – Staff reduced to less than half the number who would normally be assigned
 * – Budget and resources has been cut in half

Notice, for example, the schedule category is based on a rational estimation process. Many times we create an estimate, but we have no rational justification, but when someone reduces the schedule for us due to business requirements, we believe we are being pushed into a corner. Without a thoughtful and rational process, the estimate is not easy to defend. I have participated on projects and managed some where the developers were quite adamant about their estimates, but were able to meet the new aggressive schedule without making personal sacrifices. I have also been on projects where the developers were able to justify their estimates and were not compelled to compress their schedules. The Death March project is the one where the team can justify their estimates and are commanded to get it done in half the time anyway. The larger the project the less chance for success as it becomes more and more complicated to manage and control. Organizations used to embark on mind boggling projects in the past, but most know better to break them up into smaller more manageable components. Government agencies still embark on the mind boggling projects. They tend to be the only organizations with the budgets to sustain them.

Smaller scale projects tend to be the most prevalent on the “Death March” because smaller groups of people are more likely to stick together to complete a challenging project. They tend to be rather motivated and willing to sacrifice their personal lives for a 3 to 6 month period.

According to Yourdon, there are many different reasons for Death March projects. Startups almost by definition consist of Death March projects. It is necessary to be aggressive, and startups tend to be “understaffed, underfinanced, under managed, and hopelessly optimistic.” Many startups are staffed with a few people with technical knowledge for the business and they run the business and do all the work. Some managers run their organizations this way, and they make their commitments this way, as well.

Most of us have been on a project for which someone has made unrealistic commitments. These come from naïve and inexperienced managers, marketing/sales people and executives. They also come from those trying close a deal or please a boss. In either case, the issue is how easy will it be to move them away from the commitment when they have more information about time and cost of the commitment. Many times these naïve commitments are made because the decision maker doesn’t understand or have confidence in the estimation process used by the organization and the project team and views them as negotiable designed with ‘padding’ in them.

Some people accept a challenge to produce in an impossible time frame due to what Yourdon calls the “Marine Corps Mentality.” The innate desire to be the best and the toughest can lead to a Death March for the project team. When there is intense competition, decision makers are often motivated to compress schedules and resources to win the bid. And finally, intense pressure as from unexpected regulations or a mandatory upgrade in Operating Systems or hardware due to the termination of support for a legacy system can lead to a Death March project with little room for slack.


 * Why People Participate in Death March Projects: **
 * • The risks are high, but so are the rewards
 * • The “Mt. Everest” Syndrome
 * • The “buzz” of working intensely with other committed people
 * • The naïveté of youth
 * • The alternative is unemployment
 * • It’s required in order to be considered for future advancement
 * • The alternative is bankruptcy or some other calamity
 * • It’s an opportunity to escape the “normal” bureaucracy
 * • Revenge

While it’s not always possible to excuse yourself from a Death March project, many people are motivated to participate. The list above compiled by Yourdon are the top reasons people participate. Note that some of the reasons are due to the consequences of not participating, but many are more positive motivations such as the thrill of doing something challenging (“Mt. Everest” Syndrome) or the change of pace or even the investment in future career growth.

There are other simpler motivations such as the need to feel wanted or you have no other life, or you suffer from eternal optimism, etc.

The IT Project Manager needs to be adept at working within the political climate of the business. It is important to recognize the politics around you because it will come in handy if you do end up on a project that is politically motivated. Creating a network of colleagues will aid in removing smaller roadblocks that can impede project success. In an environment of competing goals, compromise is essential.

Perception is reality. The development world can be very black-and-white. In business, the appearance of something is as important as its substance. This is a frustrating reality of business. Recently, I judged an engineering student ‘debate’ regarding a technical issue. The teams with the best papers and question and answer sessions went into the final round. In the final round, the team with the most professional presentation, demeanor and appearance won the debate. Afterwards, the panel learned that the losing team had the best research to justify their position. Perception is reality.

The flipside to this is // evaluate the meaning behind the message ////. // Just because you are direct with your communication, don’t assume everyone is the same way. Many people don’t share their motivation for a variety of reasons, and many people will talk the corporate line but walk their own. Watch actions to determine if you can accept what people say.

Be organized. In a role where meetings make up most of the day, and decisions are manufactured across business units, it’s critical to document everything. This helps you protect yourself when something goes wrong, and it lets you keep yourself and your team aware of decisions and commitments.

Don’t be afraid to admit mistakes. Once a mistake has been made, you can’t change it, but if you admit it, it’s easier to move on towards resolution. It can build credibility, and it will save time. Whether you are the project manager or a team member, it is critical to identify the key players. In Week 1, we talked about the stakeholders, and we revisit that topic here using Yourdon’s terminology as a map. We will also consider some players we did not discuss previously.

There are cases where a project takes place without an owner. According to Yourdon, “you won’t see many Death March projects initiated with out a clear command from an owner.” With a Death March project, the project manager often has no contact with the owner. This can be someone very high up such as the CEO. The communication between the owner and the PM may be filtered through the organizational hierarchy. That means the original demand the for the project can be easily distorted through the layers of the organization. Often only the deadline is the original constraint, but each layer tacks on additional constraints such as budget or functionality or methodology or team members. The Project Manager should attempt to engineer a face to face meeting with the owner to eliminate unnecessary constraints.

In Yourdon’s terminology, the customer is the one who will use the project output. His advice to the PM is to realize that customer/user issues are magnified in a Death March project. It is important to remember that the objective of many IT projects is to save the organization money, and oftentimes the result of automation is the reduction in labor. Users/customers are not typically anxious to help you develop requirements when they feel threatened.

Yourdon identifies some **typical “loser users.”**
 * • Vendors whose legacy system will be replaced.
 * • End-users whose jobs will be replaced.
 * • End-users who like the existing system and do not want change especially if they believe change will be less functional and less convenient.
 * • End-users concerned about their own skill level being insufficient to operate new system
 * • Managers whose budgets will be reduced with the new system
 * • Managers who believe the project is too ambitious and will fail
 * • Managers whose influence and overall power will be diminished…or the manager perceives it will be diminished.

According to Yourdon, “Shareholders are effectively ‘co-owners’ of the system…there’s a tendency on the part of some project managers to avoid these individuals if possible, on the theory that the project owner can speak for the group—and, understandably, the project manager feels that every moment spend coddling a shareholder is a moment that could have been spent working on the project. But just as the shareholder can participate in the decision to authorize, approve, and pay for the Death March project, they can be involved in decisions to cancel the project. If they feel they are being ignored, they are that much more likely to do so.”

According to Yourdon, “A Death March project without a champion to defend the team’s disregard for bureaucratic rules, and to support the team’s decision to use risky techniques and technology, is a lonely miserable experience,” A champion is someone who is a friend of the project, perhaps because the career of the project manager is important to him or because of the impact the success or failure of the project will have on the overall organization or some other equally tangential motivator. A champion is usually not involved in the project and is most effective when he has standing in the organization to eliminate unnecessary roadblocks for the project.

Moving from the political aspects of projects and focusing on process, we explore a new concept – triage.

In a project that has impossible constraints, it is reasonable to separate requirements using the triage philosophy. By creating categories such as “must do”, “should do”, and “nice to have” or “could do”, it is possible to focus on the important requirements first. Often most of the benefit of the project is derived from the “must do” category and the users will not request the next level of requirements.

This becomes tricky when a project has been ongoing and descends into a crisis mode. This is when the Project Manager – usually the new project manager who replaced the one who didn’t evaluate requirements and scope early on – arrives and performs the triage process on the project in crisis. Since the organization recognizes, there’s a crisis, it is possible to begin the negotiation on what can be done based on what must be done.

The key to the success of this process is for all stakeholders to agree on the need and to participate actively in the categorization of the requirements. Some organizations have experienced so many Death March projects, they actively manage requirements in this manner from the very beginning.

//Successful completion of projects depends on managing requirements throughout the process//. //(In Instructional Design language, requirements could be replaced with needs assessment.)//

Death March projects highlight some of the worst behaviors in an organization. They also give us the ability to look at what can go wrong and find remedies. In his book, Edward Yourdon provides a lot of insight on how to spot the Death March project and how to live through them. His words on politics are useful regardless of whether the project is overly aggressive or reasonable. He shows how the use of the tools and techniques discussed in this course can improve project success and can help avoid failure.