Robert Ryan PMP

Software development projects are unsuccessful for various reasons. They are not always the fault of the Project Manager but for this article I will focus on mistakes a Project Manager can make that will lead to an unsuccessful project.

Ineffective communication:  90% of a PM’s job is communications. That is a fact stated in the PMBOK.  If a PM can’t effectively communicate to all stakeholders then important messages may be lost and questions that need to be answered to clarify a scope issue can go unanswered. It is the job of the PM to be a mouth piece for the team. It is simply the most important thing we do and without a PM who can effectively communicate a project will never be successful.

Allowing scope creep:  This is the single biggest mistake most project managers make. As a PM you always need to check with your technical resources if a customer request is out of scope. The request(s) may not seem like a big deal to you but it could be adding a lot of additional work to the development team.  Usually it is not one request but a series of requests, “small favors” as the customer will usually put it that can spell doom on a runaway project.

Underestimating:  I have run into this problem over and over again working for various sized businesses and project teams.  Developers will give their estimate and go on the low end or will give an estimate based on the experience of a senior developer and then assign the work to a junior developer who will take a lot longer to complete the task(s).

Creating an unrealistic project schedule:  To piggy back on the idea of underestimating if a project schedule is unrealistic then this is a recipe for disaster.  It is extremely important to review the schedule with each stakeholders group (BA, Development, DBAs, QA) and have their buy in that the schedule is accurate.

One of the myriad of roles a Project Manager has to play is one of a facilitator. A successful facilitator does not solve the problems for the client but rather they help the client solve their own problems.  Here are three steps you can take to become a more effective facilitator:

Be prepared:  Do your homework before attending the meeting. Make sure you fully understand what the issue is and what the different points of view are. Also take the time to understand who the stakeholders are and what role they play on the team. I think it is also important to interview each stakeholder and obtain their take on the issue and what they feel the resolution is (or should be).

Keep all of the participants in the meeting on point:  Once in the meeting keep everyone focused on solving the issue. There will be stakeholders who bring their own personal biases and opinions to the discussion.  If other issues crop up then write them down and establish a “parking lot” to address these issues at a later time.

Once the meeting is over follow up on action items:  Over the course of the meeting keep track of all action items that must be completed. Make sure all attendees agree on the follow up items and who is responsible for completing each item. Then follow up on each action item to help bring the issue to a successful resolution.

Project management success is based upon a myriad of factors and can be measured by numerous units of measure (the triple constraints, client satisfaction, keeping projects within budget, etc.). It doesn’t matter what parameters you use to measure project success there are some basic tenets that can be implemented to ensure project success.

As I have always discussed in this blog planning is probably the single most important element to project success is planning. Without a well thought out detailed plan (that covers all known contingencies) there is no way a project can be successful. When scope change happens (and it will happen) document it and update the plan. Once this update has been mad then communicate the update (as well as the ramifications of the update) to all stakeholders.

My second element of success for a Project Manager is to successfully communicate. The PMBOK states that 90% of a PM’s job is to communicate. The PM has to be the facilitator of all communication within the project team as well as with outside vendors working with the team. The PM has to be comfortable with speaking to a wide variety of stakeholders and making the communication relevant to each group.

The third and final factor for success is to manage risks and keep scope creep to a minimum. Risks are not necessarily a bad thing but they must be documented and communicated to the team. If the risk is harmful to the project then a mitigation plan must be conceived and implemented by the team. In addition to keeping risk under control scope creep needs to be effectively managed. Ask the stakeholder why they are asking for the changes and explain to them the ramifications these changes can have on the project. This simple act of communicating can often lead to a negotiation or the complete removal of the request (scope creep) by the customer.

There will always be issues that come up when managing a project. Without issues there would be no need for a Project Manager. There are some great ways to handle these ubiquitous issues when they crop up.

When meeting to discuss the issue(s) it is important to thoroughly capture what the issue is. Make sure everyone on the team has a clear idea of what the issue is. You don’t want anyone leading the team down Primrose’s Path by chasing after a solution that won’t solve the issue at hand.

During the meeting it is important to capture action items/next steps that are needed to close the issue as well as designating one person to take ownership of the issue. At the end of every meeting I think it is important to review next steps/action items and also discuss when we will be getting together again to discuss our progress.

Additionally it is important to empower team members to not only bring up issues when they find them but to also think of a preliminary solution when presenting the problem. It is this creative problem solving (and not just presenting the issue) which will help someone advance further in their career.

Finally it is important to work on the solution of the issue until it is closed or solved. Work on the definition of closed with the person being held accountable and then work towards fulfilling that definition.

What are the qualities of a good project manager? Quite often project management skills are learned on the fly and not in a formal academic setting.  Therefore my suggestion of the qualities of what makes up a good project manager are not skills that can be taught but rather assimilated through the process of learning to become a project manager.
1.      You have to learn how to deal with ambiguity. Most project managers are very detail oriented, factual, and are meticulously organized. These are all vital qualities of what make up a great project manager but the reality is that projects are none of these things. Quite often projects act like a petulant three year old. It often takes time to solve issues and risks that arise on a project and this time can lead to confusion and a feeling that you are riding a roller coaster. Neither of which align with the adjectives detail oriented, factual, & organized. Herein lies the ying and yang that a highly detailed organized person must learn to grow comfortable living with a certain amount of chaos on their lives.
2.      The second thing a project manager must do is prioritize. Maybe it is because of my “advancing age” but I find to very difficult to multi task well. I can do four different things at once but none of them will be done well. No a project manager has to be able to constantly reprioritize their tasks for the day. Sometimes this is done every few hours but I normally stick to prioritizing my tasks at the end of the day (for the next day) and right after lunch. I feel those two times are great to take stock of what has happened over the course of half a day of work & then tackle any new priorities that pop up during that period.
3.      Next a project manager has to take ownership of everything on the project. Although I am not a developer (and have no intention to ever code anything in my life) I have to take responsibility for when a bad piece of code is written, tested, and released to production. Mistakes are going to happen and when the project manager accepts responsibility for these mistakes I really think it helps build rapport with the team because they know you are not just looking out
for yourself but for the entire team.
4.      I think the third skill a project manager must learn is negotiation or diplomacy. When working on resolving a problem with a project the project manager has to obtain a wide variety of opinions to help solve the problem. It is a great project manager who can find the middle ground and have all of the stakeholders agree on the solution. Not everyone is going to be happy (because they believe that their opinion is the most important and the project manager is a fool to not follow it completely) so the project manager has to sell the solution (through a series of negotiations with varying stakeholders) as the best outcome for all stakeholders.
5.      Finally a project manager should also be honest.  This goes hand in hand with negotiation. The project manager has to paint an accurate picture of what is happening with the project and not tell everyone what they want to hear. I have always said that the project manager is the canary in the coalmine, the first person to start communicating when there is an issue.

There have been times in every project manager’s career when a project they had started working on had to be stopped for whatever reason.  It is frustrating and also an incredible waste of resources but sometimes it happens. Here are some reasons why projects are stopped:

1.      Cannot Keep Within Budget
This is probably the most common reason why projects are shelved. If projects budgets are not closely monitored they can quickly spiral out of control. If you are spending your budget too quickly and you have to ask for more money than this will lead to close scrutiny of the project. Quite often this scrutiny spells the end of the project.

2.      Timeline Isn’t Achievable
This can be due to a lack of resource or an unrealistic plan. Sometimes these two things tie together to make delivery of the project impossible. If more resources can’t be hired or if more time can’t be given to work on the project then the motives for working on the project need to be reexamined.

3.      There is a Lack of Expertise On The Team
If a software project needs a Java developer and a Java developer is not on staff then this can quickly kill a project. A contractor can be brought in but is it really sensible to bring in a contractor for this one project? What about maintenance? Will you be able to keep this contractor around for maintenance or will you have to hire another contractor?

4.      Project Deliverable Is No Longer Needed
There are times when a faster cheaper alternative is found after the project starts that would allow the team to stop working on the deliverable.

Focusing your team on delivering quality products can be a difficult endeavor. There is always some debate as to what the definition of quality is. Quality is more than just testing. It needs to be a mantra of the team.  Below I have outlined some ideas that every team show follow to deliver high quality products.

1. Careful and Thoughtful Planning:  If a team fails to plan then quality can never hope to be achieved.  Planning involves talking to all of the stakeholders for their input and then taking that input and creating a scope for the project. Once the high level scope is defined then it is a matter of breaking that down into deliverables and then tasks to deliver the final output. As the project is being planned the Project Manager should be focused on fostering an environment where disparate stakeholders (executives, business & development) discuss the scope of the project often so that everyone is on the same page. Once all of the stakeholders are in sync then the planning process will be more apt to start the quality process.

2.  Define Done: This is a common debate for software teams. What constitutes done?  For software projects is starts with the individual team members (BA, Developer, QA & PM) delivering complete and high quality work product. Once this foundation has been established then the collective work product of each group (BA, Development, QA & PM) must produce complete and high quality output for each sprint or project. Once this baseline has been established then the teams can work together to find and fix less than high quality work output.

3.  Quality teamwork: Once the team is working together to deliver high quality work as a cohesive working unit then the next logical extension of this idea is to work together to detect less than quality work that may have been missed in previous review efforts. Team members should feel empowered to fix any issues they find so that they are not allowed to accumulate, resulting in less that high quality work product.