Tag Archives: pm

Rewarding Ingenuity Part 2

by

Back in March 2014, I wrote this post raising the question of whether we should reward ingenuity or punish bad behavior. We recently had another incident with the same daughter that had us thinking about this question again. This time, our daughter had her electronics taken away for bad behavior, specifically being rude and disrespectful. We had given her a specific timeframe for which she would have to suffer these indignities. After the first day or two, we found her watching Netflix on the family television in the basement. When we questioned her about it, she quickly pointed out that we had “taken her electronics”, but made no mention of her interaction with other electronics.

In a broader context, we often look at these types of situations and argue the gray line. We say that the offender “should have known better” or “should have known what I meant.” I think we walk a very difficult line with this argument, especially given the diversity of our workforces. Every day we interact with people who have had very different personal, work, education, etc. experiences from ourselves. There is a real possibility that they understand something differently (not necessarily better or worse).

Software projects are infamous for being over budget and delayed with the resulting solution not ever meeting the business objectives. In the traditional waterfall approach to software development, requirements are gathered upfront, and then interpreted by developers during implementation with a final delivery of a solution that hopefully meets the  customer goals. Agile methodologies address this by taking a very iterative approach to development, where constant feedback is given. This allows all stakeholders to see the execution (AKA interpretation) of the requirement and determine whether it meets the business objective.

As a project manager, I have to balance between breaking everything down to the simplest form as a means to eliminate misinterpretation and being vague enough to solicit questions, ideas and foster serendipitous moments. A team member that does only what is asked of them is good, but the team member that analyzes and challenges for the greater good of the project can be a rockstar.

In the end, is this really any different than my daughter interpreting her punishment differently?  On one hand, you want them to do their chores and listen to their parents, but on the other you want them to grow up to be critical thinkers and challenge the status quo to make the world better. This is a very hard lesson when you are 13. I’m not sure whether it gets easier to understand as we get older.

P.S. Just to close out the story, we allowed our daughter to use the family TV to watch Netflix because she very delivered her very logical explanation in a calm and peaceful manner.

Kids, Project Management & the Serenity Prayer

by
Serenity-Prayer

Source: https://www.goodnightjournal.com/wp-content/uploads/2014/02/serenity-prayer005.jpg

I’m not religious by any stretch of the imagination, but I do believe in the Serenity Prayer. It’s something I have to remind myself of often as I interact with both my kids and my projects. It provides a level of grounding. What’s the point of getting frustrated if it’s outside my control?

The nature of my personality requires that I be hands on. I want to be involved. I want to help control the outcome. But the nature of many of my projects results in things outside my control. These projects are big and complex integration projects that involve technical resources both within my organization and often within the client; and business users. Often the decision to move forward with this implementation was handled by resources higher up the corporate food chain. This means there are questions, considerations and discovery that need to take place at the beginning. The inner workings of corporate culture and the organizational power hierarchy become evident here. It is usually at this time when a decision is made that is totally outside your control, but has major impact on the project. It may be a decision to user an external intermediary for some piece, or the implementation of a business process that impacts overall timelines.

My initial inclination is to get frustrated. It’s that overwhelming feeling of wondering how you are going to accomplish what you set out to do if you don’t control all the pieces. After a little while, I remind myself that I can’t worry about things outside of my control. These are things that I can’t change. So what can I do?

  • Accept the things I can not change – Most importantly, I can recognize and remind myself that there a components of the project that I do not control, and can not change. This allows me to keep my sanity during the project implementation.
  • Establish Trust – I can establish trust with whomever is involved in the project and do my best to work together towards the overall success of the project.
  • Communicate  – I can engage fully with the entire project team and make sure everyone knows the status. There is some trial and error that needs to happen to determine the appropriate level of communication.
  • Raise Concerns & Questions – I can monitor the project situation and raise concerns & questions to the appropriate team members.
  • Focus on what I can control – It’s my job to be looking at the entire picture. What can I contribute? What ideas or actions can I bring to the table to facilitate project implementation success?

This approach is one I need to do a better job of also applying to my children. In some ways it easier to apply this to a project and people you are professionally affiliated with rather than your kids. I think the principles are the same. Yes, your kids belong to you. However, they have their own personalities and natural characteristics which combine with their unique nurtured experiences that we need to consider. I need to keep reminding myself of this as I work to establish & maintain trust, openly communicate, raise concerns & questions and focus on what I can control while encouraging them to do the same.

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. 

 

 

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.