Introduction
Problem Statement
Delivering high-quality software applications within demanding time constraints has been a project management reality since computers first walked the Earth. The drive to produce feature-rich applications faster than the competition continues to be the hallmark of successful software development organizations. As project managers, how do we balance tried and true project management principles with these seemingly contrary realities? Fortunately, there are many documented methods that successfully attain this goal.
Instructor Background
I have been an IT project manager for almost 20 years. My experience spans both the private sector and the public sector, and I‘ve been both a direct employee and a consultant. I have led approximately 60 projects, large and small, approximately 80% of which were successfully delivered on time and within budget. Over the course of my experience, not once has anyone told me “go ahead and be late” or “please overspend the budget.” Time and money are always the customer's top concerns, and rightly so. How do we, as project managers, provide our customers with the highest quality product in the shortest period of time at a reasonable price? The answer is simple to state and difficult to execute: plan effectively and deliver aggressively.
Project Preparation
Plan the Project
I ask myself two questions at the beginning of every project: “What are the deliverables?” and “What's the most efficient way to produce them?” The answers to these questions keep me focused on the project goals and keep me from being distracted during the project.
Anticipate Distractions
Projects with short time frames have a common denominator: increased adrenaline. This usually shows up in the form of distractions from the real work of the project, which is defining, writing, testing, and delivering the software. Some of the most common distractions that occur on projects with short time constraints include:
• Increased management involvement (e.g., “will we ship on time?”)
• Raised intensity level (e.g., “will we lose our jobs if we don't ship on time?”)
• Decreased design and test time
• Narrow margin for error (i.e., it must be done right the first time)
• Heightened project risk (see above).
Fortunately, there are reliable approaches to address all of these distractions. These approaches use resources, the software feature set, and quality to remove most if not all distractions from the project.
Approach #1—Add Resources
Adding resources once, at the beginning of the project, removes the learning curve problems associated with bringing people on later in the project. Remember that resources may include hardware, software, and space, as well as personnel. I would recommend not adding resources at all unless you can add them at the beginning of the project. Adding resources late in the project will typically increase your budget burn rate and decrease project progress right when you need to deliver.
Approach #2—Clarify the Feature Set
Removing features at the beginning of the project helps the team to see the delivery date as not quite so imposing. It may also clarify stakeholder expectations for what is being delivered in that it may be the first time that a clear deliverables list is produced. Determine the minimum feature set by clarifying and documenting user needs versus user wants. Set management expectations that delivering the “user needs” feature set constitutes a functionally complete release. This may be difficult to accomplish because management may be insistent regarding specific features. I have been able to overcome this obstacle in the past by including management in my project planning sessions. This allows management to see the cost and schedule associated with every feature and usually results in feature removal instead of schedule expansion (because, after all, we do have a short time frame).
Approach #3—Set Quality Expectations
Point out that your team will deliver a high quality version 1.0 release of the software package. Remind the customer that all software has undocumented features (also known as bugs) and that version 1.0 releases have a larger share of those features than other versions. Include the customer as you plan how to document and address the bugs, which usually results in the customer tacitly agreeing to delivery of version 1.1. Convince the customer that bugs will be fixed by including find bug/fix bug tasks in your project schedule.
Whichever approach or combination of approaches that you use, I encourage you to keep your eye on the goal: to deliver the most features with the highest quality within the constrained time frame.
Project Delivery
Now that we've set up the project for success by maximizing resources and minimizing the feature set, we need to turn to the day-to-day issues of managing the project.
Provide Leadership
How you lead your team will directly impact how the team interacts both with you and with other team members. Critical team leadership components include determining your leadership style, becoming accepted by the team, leading proactively, and removing obstacles from the team's path.
Determine Your Style
Leadership style is critical in short timeframe projects. A “classical” project management style (i.e., “what can you do for me today?”) can focus the team in short bursts to produce deliverables quickly. A “servant leader” project management style (i.e., “what can I do for you today”) empowers team members to set individual project goals and then meet or exceed them. The latter, in my opinion, is the most effective way to lead a project team.
Are You on the Team?
There are many indications of a team's acceptance. Some of the ones I pay closest attention to include:
• Does the team provide me with information without me asking for it?
• Does the team invite me to lunch with them?
• Does the team keep talking when I walk up?
The answers to these questions tell me how much work I have to do to get on the team. Once I‘m on the team, I want to be viewed as a productive team member by the rest of the team. The leadership principles I choose to follow portray who I am and what I bring to the team. Some of these principles include:
• Share the credit: If it's good, then I tell management that the team did it.
• Keep the blame: If it's not good, then I tell management that I did it.
• Be a servant: Do work that no one else wants to do.
• Implement sound processes: Coach team members so they achieve results more quickly.
• Model confidence: Encourage team members to act with authority and responsibility.
Just as there are leadership principles to embrace, there are also principles to avoid. I’ve found the following to be the most effective team-killers:
• Take the credit
• Pass the blame
• Say one thing to the team and another to management
• Tell everybody how to do their job.
Be the Leader
Give the team someone to follow who cares about the product. Instill in the team by your words and actions the importance of what they're doing. Give the team a reason to care.
Proactively determine what's holding them up and get it out of their way.
While you're gathering project status, try to find out what's frustrating team members the most. It could be that a critical input has been held up or that a resource that they need isn't available when they need it. It's always best to learn about issues like these as far ahead as possible; however, emergencies should be handled whenever they occur because your actions will send a strong message to the rest of the team.
Manage Change
Someone once said, “The only thing that's constant is change.” Short time frames mean almost constant change. Two methods that I use to manage change are the use of a rapid software development methodology and resistance to add features.
Use a Rapid Development Methodology
If we can achieve milestones and produce deliverables quickly, that will reduce the effect of those changes on our projects. Some methodologies that fall into this category include Rapid Application Development (RAD), Evolutionary Prototyping, and Extreme Programming. It's very important to use a methodology that works well in your business culture, so make sure that both development and management are in agreement with your choice.
Resist Adding Features
On a project with demanding time constraints, change management focus moves from communicating and reviewing changes and their resulting impact to resisting feature change at all cost. Many things can and should change during the project. Developers may devise a better design or testers may determine that some test cases can be combined. However, avoid scope creep at all cost because project time increases when features are added or changed. This may be difficult to do when management “requests” an additional feature. As I mentioned previously, I have found the greatest success combating these types of changes when I have teamed with management to determine the cost and schedule impacts of adding the specific feature.
Manage Deliverables
Deliverable management can be neglected on short time frame projects because of the focus on the day-to-day activities of the team. I have found that defining deliverables clearly and avoiding surprises help me to effectively meet the expectations of both the stakeholders and the team.
Define Deliverables Clearly
The greatest barrier to project success is unclear deliverable definition. Simply put, if you can't define it, you can't deliver it. Stakeholders have a strong tendency to redefine unclear deliverables, and no two stakeholders will have the same deliverable definition. I meet with stakeholders to define their use of the project deliverables. This provides me with a great indicator of how they define the deliverables.
Avoid Surprises
Deliverables will come into sharper focus as the team gets closer to the end of the project. When this occurs, meet with the stakeholders to validate the team's direction and to ensure deliverable acceptance. You should be prepared to explain how the team's deliverables fulfill each stakeholder's expectations of the project. This should substantially lower the risk of one or many stakeholders refusing to accept the deliverables.
Hold Effective Meetings
Meeting management is an art form. Meetings ebb and flow depending upon the time of day, the personalities in the room, and a host of other variables. I manage meetings best when I prepare adequately and follow-up effectively. A typical meeting may include the following.
Meeting Preparation
Meet with a purpose. Ask yourself if you would want to attend the meeting. Get the right people there, including stakeholders. If the right people aren't there, then postpone the meeting until you can get them there. A well-defined agenda should be sent out a minimum of two days before the meeting so attendees can prepare for their participation.
During the Meeting
Start on time, even if everybody's not there. This sets the expectation that meeting participants need to come on time in order to know what's happened in the meeting. Also, resist the urge to summarize the meeting for each person who comes late. Instead, encourage them to ask you after the meeting for an update. Stay on the agenda. The group may even help you with this if you ask them for agenda items. Discourage sidebars by stopping the official meeting proceedings to wait for the alternative conversation to conclude. Another approach I‘ve used effectively is to walk over to the sidebar participants and stand beside them while continuing the official meeting proceedings. Conclude the meeting when all meeting business has been accomplished rather than keeping everyone together until the meeting time has been consumed. At the end of each meeting, review action items and confirm ownership. This sets the expectation that work will continue between meetings on the project.
After the Meeting
Treat meeting action items as if they were tasks on your time line. Meet informally with action item owners to determine if they are having any difficulty completing the action item. Remove any obstacle to their success. This will encourage them to volunteer for further action items as well as ensure timely completion. When a group fulfills its mission, stop meeting. Have a celebration at the end to review the groups’ accomplishments and thank the team for participating.
Manage Risks
Risk identification and management is a critical component for any project, but especially so for one with a short duration. It's also the most likely component to receive little, if any, attention because of time constraints. I like to manage risks by identifying them at the beginning of the project, implementing risk mitigation and contingency plans, and re-scoring risks regularly.
Identify Risks Up Front
Spending time at the beginning of the project to identify potential risks is a very good time investment. Unidentified risks can produce time delays and potentially cancel projects. So, it's very important to capture every risk that may affect the project. To help ensure that I discover all the critical risks, I use the following risk categories:
• Technological—Has this technology ever been implemented successfully?
• Political—Is there management who wants this project to fail? Does this project run contrary to corporate direction?
• External—To what extent will vendors be involved? Are there standards (e.g., ISO 9000, etc.) that affect the project?
• Stakeholder—Do I understand their individual agendas? Are those agendas compatible?
• Legal—Are legal agreements in place? Are lawyers one of the stakeholders or more of a service provider?
• Resources—Will they be available when they are needed?
The answers to these questions, as well as related questions which surface as a natural part of the risk identification process, typically allow me to identify the critical risks on any given project.
Implement Risk Mitigation and Contingency Plans
Risk mitigation plans provide the means to lower risk or alleviate its affect entirely. This plan focuses on either removing the risk entirely or lowering its impact before it occurs. This represents your best opportunity to proactively affect the success of the project.
Risk contingency plans provide the response to a risk after it occurs. The implementation of this plan can be likened to triage, where you know what the process is but not what actual results will occur. Therefore, it's best to mitigate risks aggressively so you don't have to implement risk contingency plans.
Re-score Risks
Review all risk plans regularly so that they stay current and provide maximum benefit. Treat your risks like a worry stone that you touch regularly and know intimately. This provides the best assurance that risks will not crop up without warning and adversely affect your project.
Solve Problems
Problems are escalated particularly rapidly in short time frame projects. People want to solve the problem quickly, sometimes so quickly that they solve the wrong problem. Adequate problem definition is critical to the problem solving process. After the problem has been defined, encourage teams to resist the quick, obvious solution and brainstorm potential solutions instead. Spend some time defining the alternatives, perhaps using a pro/con approach, so that the team understands what each alternative solution brings to the problem. Score the potential solutions using either a show of hands or multi-voting. I usually include the tasks on the project schedule to ensure that the solution is actually implemented. I have found that using this disciplined approach saves time and reduces the frustration associated with solving the wrong problem.
Communicate Clearly
Project communication always has two faces: management and team. Short-term projects fare best when both communication channels are running efficiently and effectively.
With Management
It's important to recognize that the project gains or loses momentum depending on what management believes. I encourage management to think positively about the project by providing good news along with the challenges that the team faces. I also develop alternative solutions to present with the problem so management becomes a partner in the problem-solving process. I have found it important to learn about each manager's information needs and communication style so I can provide them with the information that they need in the form that they can most quickly digest. In general, I try to remember the importance of communicating the right content to the right person at the right time.
With the Project Team
I like to use Hewlett-Packard's “Managing By Walking Around” because it provides me with opportunities to hear what the team needs and then to share appropriate information. Whatever method you use, be sure to focus on the information needs of the team. Always provide accurate information, even if you have to tell them that you're unsure and have to get back to them later. Let them know when you will provide the information and then keep your appointment. Work aggressively to unblock communication channels within the team so each member understands what others are doing and how it relates to their individual tasks.
