Mastering Project Management Within Any Development Environment

To be a successful project manager in a software development environment, one must know more than the “best practices” for managing a project. In software, it is often not known what the final product is going to be at the inception, nor is it known the path that will be taken to create the final product. It is a project managers responsibility to recognize how much can be predicted, how much will be created along the way, the process that will be used to create the product, and how to successfully communicate all of this to the stakeholder – an end user, a purchaser, a contractor, a developer, or a project manager – while keeping time and budget constraints in check.

Perhaps one of the biggest challenges in project management, as it applies to software development, is choosing the development method  (assuming the upper management or client will let the project manager make that decision) from a wide array of choices. Lets take a look at mastering the art of project management in any development environment, focusing on the differences and challenges of the high-level categories of iterative or waterfall development processes, rather than breaking it down into each method. Various people make distinctions among development processes, but the distinctions are neither widely agreed on nor that important compared to the iterative/waterfall dichotomy. One important factor that is taken into consideration is that a master project manager has more control over the development environment than the other way around. A common occurrence in today’s business environment is stress incurred from naming the development method used but not actually following the method’s rules, many times out of a lack of understanding of what the rules actually are for any given methodology. A strong project manager will understand that rules are meant to be broken and tailor the style to meet the project needs. Call the method what you will, but in the end the right development process is the one that delivers a successful product through a hybrid approach. No matter the approach, there are a few specific phases that must be present in any SDLC (software development life cycle) if anything is to happen: planning & requirements analysis, design & development, integration & testing, and implementation.

I’m going to assume here that there would be no need for a project manager if there were no project, therefore, a software need has already been identified and it is now time to plan everything. The planning & requirements phase of a SDLC is perhaps the most varied cycle depending on the chosen development method. This is also the point where the general development method should be chosen. There are seven factors that should be questioned to find the proper fit of process to project:

1. The kind of system you are building.
2. The technology you are using.
3. The size and distribution of the team.
4. The nature of the risks.
5. The consequences of failure.
6. The working styles of the team.
7. The culture of the organization.

Many of these 7 factors can be analyzed and tentatively decided upon before a team is even assembled, however, it should be a continual analysis during the course of the entire project. Before development begins, and after the team has been assembled, the official decision making can begin. The most suitable process for a software project should be discovered during the initial requirements phase, not before, when a team can tailor the framework to best fit the project needs.

The Team

With larger companies that have a pool of talent, a team should not be assembled until the initial scope of the project is analyzed and the first ideas as to what type of development method have been assumed. It is then that a project manager should be assigned and asked to assemble the team. A project manager is an integral part of the team; most computer programmers suffer from profound deficits in the following areas: thinking critically about what a computer application should do, writing down a design, writing down an implementation plan, documenting important features or design decisions, exercising good judgment and communicating project status. A PM can fill these slightly important needs. As humans, it is easy to get comfortable in our ways, and it is important that a project manager be adaptive to accommodate any project environment. The PM approach should be tailored to the project type, however, the PM should also assign the type based on the project requirements. It is not fair to any project that a PM use their bias to assign a project type only because they are more comfortable in that environment, when doing so could jeopardize the projects success. This is where the importance of understanding multiple project methods and experience can prove to be a huge asset. That being said, we are still human and one PM will be more suited to a certain method than another.

The most important factor in a projects’ success is the quality of the people on the project and how well they work together. The process and tools they use are strictly second-order effects. Choosing the right team can facilitate progress and release the temptation to micro-manage. It is important for the PM to create a self-driven team, rather than relying on command and control. A common practice suggested for iterative development, but that also should be recognized in waterfall methods, is choosing teams that are selected based on the skills required for the project. The second concern which should be addressed when selecting a team is availability. For smaller companies that may only have enough employees for one or two teams, the luxury of choosing members by skill set and availability might not exist. In that case it is especially important for the PM to develop a strong plan to deal with adversity.

Planning

A projects first stage shouldn’t deal with product design, but rather with designing the development process itself. Two main positions exist in software development: classic plan driven development and more contemporary iterative software development. One of the most well known methods in plan-driven software development is the waterfall model, where each phase of the project is planned in advance and there are clearly delineated interfaces between phases often called “gates”. The more agile iterative development methods kick in when not all of the solution is clearly known. What’s needed is not a single software methodology, however, but a rich toolkit of process patterns and “methodology components” (deliverables, techniques, process flows, and so forth) along with guidelines for how to plug them together to customize a methodology for any given project. An idea of the general properties of the two development methods is displayed in the table below.

It is important that the PM learn the patterns and attributes associated with many of the most popular development methods to be able to function within them, change them, and successfully support and explain to stakeholders why they are being used on a project.

Requirements Analysis

Properly identifying the requirements of a project is the first challenge in mastering project management and planning a project. These requirements are the key to deciding on the right development method, and a good understanding of all models is integral in continually making intelligent management decisions.

Requirements analysis can initially be overviewed by just the PM, but continues with the entire team working together. Many times this entails brainstorming and modeling sessions using tools such as the UML (Unified Modeling Language) to map out the plan for the software project. This plan can also serve as a great identifier of the development process that should be used. Consistent with the model above, if the system has most of the requirements known at the start, it is much easier to take a waterfall based approach, which endures because of the desire for predictability in software development. Predictability promises less deviation from a solid plan and helps with recognizing costs and duration, and is good for keeping happy stakeholders. Predictability does not, however, dictate that a waterfall method must be used. It may be safer to try and steer the stakeholders towards a planned yet flexible process to allow for any change. Predictability is an illusion and cannot exist within today’s changing technology and market conditions, and companies and clients need to face the reality of constant change. It is the PM’s job to communicate this change well.

Client Needs

The client is just as important as the software requirements when it comes to selecting the right software development method. A client who wants to take a back seat in the process will probably feel more comfortable with a plan-based approach to development. Iterative development methods require heavy client involvement on a regular basis and end up failing if this involvement is not achieved or sustained. Many customers now are specifically asking for iterative methods in their software projects because of their adversity to surprises (often arising with the low communication and lack of iterations in the waterfall method). Unfortunately, it is also common that if a PM cannot keep the client involved, the project tends to revert back to “management by plan” which, in turn, severely limits agility resulting in more of a waterfall mode. Customer involvement greatly dictates the development method that will be most successful for any project, and a good project manager stays alert to this. The customer and the PM are both decision makers in a project with the customer knowing the business, and the PM knowing the technical aspects, however, the end decision should be made by the PM. As long as expectations are properly documented and consistently met, the client will trust the PM and the decisions they make. Customer involvement must always be monitored as a more customer-centric iterative process has a greater frequency of failure if the customer wants to be on the sidelines.

The PM must also figure out what the users and customers of a software effort want the system to do to properly identify the requirements. If less is known of the requirements, an Iterative method – a much more customer-driven approach – has a better chance at success because of the ability to innovate as the life cycle develops. Innovation starts with requirements, and elaboration should include diverse perspectives and skills including the end customer, developers and testers.

Planning The Plan

Mastering project management also depends on being able to master your project management plan. A tall order when a flexible plan is required to properly manage a dynamic development environment. Not only should there be an SLC (System Life Cycle) chosen for the development, but there should also be a supporting PLC (Project Life Cycle) in place for the management of the project. A project manager should have a general plan laid out that they generally follow, as well as common tools that they use, but there is no one “best practice” that fits all projects & situations. Managers must select a combination of practices and integrate them into a coherent process that’s aligned to their business context. Changing from a static project management plan to one that can be more dynamic can have many differences:

1. Focusing on planning & scheduling using iterations as opposed to planning & scheduling an entire project.
2. Using teams that are smaller than traditional teams where team members are selected based on the skills required for the project.
3. Including customers throughout the project and meeting on a daily basis for a short period of time in contrast to traditional weekly meetings.
4. Creating less documentation.

Though a master project manager will have a variety of strategies for different development methods, just like a website, it is better to be dynamic than static to allow for changes as they arise. Any one of the above items can, and should, be adjusted if the project success is being threatened.

DESIGN & DEVELOPMENT

Communication

Design & development happens in every project. It may be in a big gathering of the minds at the start of a project in true waterfall fashion, or it may come in iterations. However this happens, it is important the the PM constantly keeps up communication with all stakeholders. The PM must also understand that communication consists not only of speaking, but is also written and body language. Good communication is at the core of all successful projects, and there are some simple ways to keep communication flowing:

1. Proximity – Greater communications come from a team that is closer to one another.
2. Temporal Proximity – Teams that work the same hours have better communication.
3. Team Morale – High morale = high communication.
4. Tools – Complicated tools = communication barriers.
5. Anxiety – Reduce anxiety by identifying the communication styles your team prefers and utilizing this knowledge.

Keeping a project under control relies heavily on good communication, especially when in an iterative environment there are rapidly changing variables.

The Team Revisited

Whether or not you use a waterfall approach, you still do the activities of analysis, design, coding and testing, and you need a team that supports all of these activities. The PM needs to begin the project by facilitating a rhythm that they will carry through the entire life cycle of the project. This rhythm is essentially the flow of good communication as mentioned above, keeping anxiety down and morale high. A PM with a good PLC in place, a strong understanding of requirements and development cycles, and good organization can manage without missing a beat, infecting the entire project team with an unbelievable energy.

This rhythm and energy that a PM has worked so hard to build can also be crushed if the right team is not in place and managed properly. An important factor that should constantly be reviewed in any project is how many people are involved. The size of a project team can depend on the number of requirements and how large the project scope is. For larger teams there is a greater need for more efficient communication and co-ordination. Before you lose morale and energy with a larger team, increased control of the project can be gained by the PM by continually assessing time estimates through communication with the developers. A truly adaptive PM also understands that just like requirements, team members can also be changed at any time.

Only around 20 percent of all IT projects are completed on time and within budget; an average project takes twice as long as estimated and is approximately 200 percent over budget; and projects regularly only deliver 2/3 of their planned scope. Definitely a scary statistic which can be mostly mitigated by the management of a PM and a properly selected team. Team selection continues through the entire project as new tasks come up. These tasks should be allocated as people become free, rather than on the basis of expertise, which reinforces the development of silos and indispensable “heroes”. Morale, as we all learned in gym class, stays higher when there is no “I” in team.

Development

Development has begun and it’s time for the PM to go to his office and wait right? Of course not, that is a very poor habit for a project manager. Many times the PM is a previous developer who has moved up in the company, but it is important to know that the primary task of the manager is to have the right people do the correct work and, ultimately, to get the tasks done in the most efficient and least problematic way. Mastering project management depends on mastering your project management plan, which does not include solving code problems. In fact, there should be very little problem solving and much decision making. In the book The One Minute Manager Meets The Monkey, it is suggested that the manager train the employees (in this case the developers) to bring at least two suggested solutions to any mention of a problem, practicing “hands-off management”. The best way to develop responsibility in people is to give them responsibility, and the best use of your time is doing your own work, not the work of everyone else. Project managers can make more effective decisions when supported by the right tools and techniques for leading a project, and using those tools and techniques in the right way will have direct impact on the delivery of a successful project.

Both iterative and waterfall methods have their place and can be effective in different project contexts, depending on how much uncertainty exists and how much flexibility a team requires. Allowing a project to move around between an iterative and waterfall structure is essentially balancing flexibility with reliability. There is a danger in dynamic environments where allowances for change in a project can send the project out of control. This may be the point where a PM may call for a requirements freeze, kill the project entirely, or just revert back to a more waterfall approach for a period of time. Rapid changes in the environment, including tools and methods, and attempts to innovate, act to push the project into an iterative model, increasing unknowns. The challenge is to conduct exploration at a greater rate than the emergence of environmental change, keeping requirements relevant. Change in requirements can be counterproductive to the success of the overall project and should be carefully scrutinized.

IN RETROSPECT

A good way to remove yourself from the mindset that you know whats best is to keep a detailed log of what works best in each project. Learning from the past is invaluable and often overlooked. There are many differences in the iterative/waterfall dichotomy when it comes to documentation at the development level, however, a strong plan for documentation should be in place for the PM. There are many types of documentation in a project including documentation for: the team, the management, the client, the PM, or simply to generate ideas.

Tracking results from elements of different development methods and how they were used in problem solving can be invaluable to the future success of software projects. The use of qualitative methods would not only provide insight into qualitative results, but is a practical and necessary avenue to defining meaningful and consistent metrics; qualitative investigation could provide the context & background needed to compare results from different projects even when different methods are used. A well organized resource for learning from past decisions is the key to making future intelligent decisions.

For the development team in an iterative environment it is better to build something and then document it rather than document something and then build it. Even with a waterfall style project, this should prove true as well. Though waterfall suggests planning and documenting the entire product at the beginning, there is still a chance that it may live in a gravity-free environment or may move over to an agile process. A client may request a requirements or functionality change, negating the relevance of previously created documentation which could throw some wrenches into your team morale and overall cost. Development documentation has a knack for becoming irrelevant and out of date. This is not the case with management documentation and it would be good to find an understanding of what documentation should be kept for statistical analysis by the PM.

Reuse is a common term to developers, but this can also be a term associated with project management when paired with the idea of learning from other projects, teams etc. Documentation is king when learning from the past and is an important part of a PM’s repertoire. Without good documentation it can be very difficult, if not impossible, to learn from your mistakes. A continual analysis of things that are working, things that are not working, and changes that you have made can provide the basis for a solid decision making library.

CONCLUSION

With the right tools, a creative, hopelessly optimistic, and brutally honest PM can shine. Creativity can help identify next moves, optimism can recognize paths that have potential, and the brutal honestly can quickly halt a failing project. These tools are the ability to plan, select a team, make tough decisions, and keep documentation to learn from. In todays software development environment, perhaps the most important tool, is how to cater the development method to the overall environment.

In general, minimal empirical evidence exists to support the advantages of any one model over any other regarding cost, duration or quality. Requirements and clients should be the dictators of the development environment, and the environment in which a project is conducted directly affects the amount of dynamism required. The project manager should then tailor their management approach to the project type, and it should be the PM that assigned the type based on the experience they have and the documentation from previous adaptive projects. In software development events tend to arise at faster rates than is practical to re-plan for. Traditional management is simply counterproductive; it crates self-inflicted problems that seriously undermine performance.

Whether a project begins as waterfall and ends as iterative, stays the same, or wanders through many development models, there is no “best practice” for project management that can be applied. It is the responsibility of the PM to stay adaptive so that each project has the best chance for success, in the shortest time, with the least cost and the most satisfied stakeholders.