Monthly Archives: January 2016

The Myth of the Project Plan

by

 

The Project Management Institute Project Management Book of Knowledge defines a “project plan as a formal, approved document used to guide project execution and project control.” It further specifies that “it should be used to document approved scope, cost, and schedule baselines.” In my experience, a project plan is treated heavy on the “formal” and “approved” and light on the “baseline.” I think the process of approval gives the perception of longevity on the life of the plan. This minimizes the impact of the project plan as a baseline. Unfortunately this misunderstanding causes many complaints about project delays and delivery.

I was struck by this Computer Weekly quote when I conducted a google search for “project plan”: “[It] is one of the most misunderstood terms in project management. It is a set of living documents that can be expected to change over the life of the project.” This is polar opposite to how I have seen the project plan treated. The project plan is usually created at the beginning of the project, based on a statement of work, with fairly limited information. Even in cases where all stakeholders understand that the project scope is fluid, the project plan is expected at the beginning of the project and is used for making time-specific business decisions (training, user acceptance testing, etc).

Historically this has resulted in project managers padding their project plans with additional time so that the project is guaranteed to come in on time. Alternatively, the project plan isn’t padded, but issues of either scope creep, or scope reduction occur. In all cases, decisions are being made to meet a deadline, often selected artificially, which only aligns to the information available at the beginning of the project. There is no consideration to the fluidity of project implementation and information availability.

It would alleviate quite a few problems in project delivery & success if we chose to leverage the project plan as a living, breathing document. As time progresses, and additional details are obtained, the project plan should be updated. As a project team, we would be in a much better position to make decisions, and set more realistic deadlines as we get into the details and work through the development. Furthermore, sharing regular status and having constructive conversations about the state of a project and the next steps result in a more successful deployment. 

 

 

3 Pitfalls with Allowing Technical Teams to Engage Directly with Clients

by

We all inherently know that our best options are to always to go directly to a source, whatever or whomever that is. In a recent post, I advocated for allowing your project team to engage directly with customers. While I strongly believe this allows you to deliver a better experience, I do think there are a few pitfalls to avoid.

bomb_clip_art_10552 1) Be careful about the “shoot from the hip” responses – Often times in design or business discussions an inquiry will ask “how long?”, “how much?” and it is common for people to “shoot from the hip” and give an answer. There must be a structured way to balance these casual conversations, with the reality of the project status, plan, resources, investment. Otherwise, you will get stuck in the never-ending project and perpetual scope creep.

2) Balance gut estimates with discovery – Everyone is in a rush to understand how long it will take to build this product, feature or system. You need to be able to leverage your knowledge of having done similar applications, with the project discovery you need to do to understand this particular project. Too often I’ve been caught in situations where I had to explain that while a team member said they had done something similar in 10 hours, this particular implementation was going to 40. At initial thought, this seems excessive, as compared to the similar project. However, once you start talking about all the additional project management, testing and discovery required for this one versus that other one, it becomes more palatable. Make sure you vet gut estimates with actual requirements and customer needs.

3) Avoid detours – A huge risk to allowing project teams to engage with customers directly is subtle permission this introduces to go directly to the project team. I’ve seen customers who will stop engaging with ticketing systems in lieu of going directly to project teams. This introduces quite a few disruptions to the process. First it makes tracking and accountability difficult as inquiries aren’t going into a central system. Second, it can overwhelm project team members as they try to balance assigned work with the customer engagement. The project team will sometimes feel that they “have to respond.” The project manager or customer success manager needs to step in and manage the process. The team needs to make sure that they are being responsive, but doing it in a way that addresses the customer priorities, and keeps the customer involved in making those decisions.

As I’ve mentioned before, I’m a huge advocate for engaging project teams with customers. This is not a free for all. There should be a structure and methodology, with appropriate accountability and check points to adjust for the changing environments.

4 Ways Project Managers Deliver Quantifiable Value

by

It is sometimes hard to understand the quantifiable value that strong, technical project managers bring to organizations. I would go one step further and say that some people question the value (of any kind) that project managers bring to the table. Like many in operational roles, project managers are blamed for project challenges, but are often overlooked after project successes.

I searched Google for articles on how project managers deliver quantifiable value. Mostly I found articles that were more conceptual in nature about why you need a project manager or project management office (PMO) or how to get the most value out of your PMs. I didn’t find tangible ways project managers actually improve the bottom line of the organization. In an age where every function needs to be delivering quantifiable value, I was a bit surprised. I know that strong, technical project managers are invaluable to organizations, and worth every penny of their cost.

Project managers deliver Quantifiable Business Value by:

  • Reducing busy work & obstacles for the project team – It has been proven that focused, dedicated time improves the quality and reduces delivery time of technical solutions. A strong PM will handle the busy work, allowing the team to do just that. Cost savings:  Reduced hours worked for project delivery & reduced hours of non-billable rework.
  • Managing the analysis & artifacts – This is an often overlooked function of a PM. A good PM will understand the business requirements and can help facilitate troubleshooting & testing. Additionally, the PM will also be able to write & manage the artifacts (project plans, requirements, implementation documentation), which become most critical during testing & supporting the development post-implementation. Cost savings: Reduced costs for testing, support & maintenance and facilitation of support functions away from high cost developers to less expensive support resources.
  • Reducing risk – A project manager will feel comfortable managing the scope, and making decisions. The PM is willing to have those tough conversations for prioritization. Cost savings: Reduction or elimination of unanticipated costs associated with scope creep. Additional cost savings come from keeping project on schedule.
  • Improving project delivery &  allows for new work – Lastly, and arguably most important, a good PM will deliver! Often organizations get bogged down by lack of prioritization resulting in all resources making their own decisions. This chaos slows the progress of project delivery. For all the reasons outlined above, a PM will delivery projects, which will open the window for new work from customers. Incremental revenue: When PMs deliver, customers deliver too! In this case, it’s in the form of new work.

Don’t under estimate the power of a strong, technical project manager for the success of your business. While you may wonder if you can afford the cost, I would argue that a PM can pay for themselves in what he/she delivers in return.