Category Archives: Project Management

Prioritizing from the Get-go

by

As you may know, I believe many corporate resourcing & delivery issues stem from not properly prioritizing customers & projects. You can read my recommendations on how to approach those in my prior blog post. Today, I’d like to take a step back and look at prioritization from the onset of customer project introduction. In government contracting, this is called the gate review process.

A business faces immense pressure to succeed these days, facing obstacles from all directions. This might be driven from competition, or budget reductions and uncertainty, investor return or simple from cash flow concerns. Amidst all this chaos, the only real thing the business can control is how they behave. It is up to the business to pursue the business, then accept the business and support the business. Ideally all parts of the business are in sync about the choices being made. Unfortunately, that is not always the case. In my experience, most businesses pursue any prospect of business with a vigor and stubbornness, minimizing any negative feedback or concern. Many times this is done by simply not including other parts of the organization in the sales process.

These challenges can be overcome by simply asking the right questions (and following through with the outcome regardless of the answer) throughout the process. This process does not need to be too tedious. However, it should be thorough enough to have all pre and post involved departments participate in the conversation, being able to have their concerns heard, acknowledged and if possible, mitigated. Three simple questions you can ask during this process are: Can we do it?, Can we win it? and Can we make money?

Can we do it?

Fundamentally this is the first step. This step is really about reviewing your capabilities as and organization and determining whether you can deliver. Some ancillary questions include:

  • Do you have the resources? Can you get them in time?
  • Do you have the applicable skills?
  • Have you done this before?
  • Can you identify and mitigate the risks?

Can we win it?

This step is determining how you stack up to your competitors. It is also about doing an honest assessment of the work involved to ensure you can price within the required range to win it. Questions to consider include:

  • What is your existing relationship with the customer?
  • How do you stack up against the competition?

Can we make money?

While there may be reasons to pursue opportunities with limited margin, the answers to this questions should be most honest. Businesses exist to make money. Continuing to pursue opportunities where the prospect of doing so is limited puts the whole business in jeopardy. This discussion will put some key business assumptions to test about efficiencies, repeatable processes, or the reality of custom work. Questions to consider include:

  • What is the customer’s budget?
  • What is the contract type? Where does the risk lie?
  • Where do your competitors end up with price?
  • Can you mitigate the financial risk?
  • Are their efficiencies you can gain?

It is at the intersection of “yes” to all three of these questions where the optimal place exists for your business to pursue new customers or projects.  It becomes a slippery slope when only two questions result in “yes.” You may strategically choose to pursue business when you have two out of three, but these come with very severe risks. Wasted resources and degradation in customer success are two potential outcomes.

Prioritization is critical to business success. Having checkpoints at multiple stages throughout the sales & pipeline, customer success and PMO processes significantly improve your ability to work on the right projects for your customers. It also helps your ability to delivery and make money from your initiatives.

I want to thank David Stearman for his presentation on Gate Review Decision Making at the Association of Proposal Management Professionals-National Capital Area (APMP-NCA) Mid-Atlantic Conference last week. This blog post is a compilation of my notes and thoughts regarding project discovery & decision to move forward.

The Importance of Understanding Why

by

Last week my 16 year old daughter took her PSATs. While we were talking to her about how she thought she did, it became very evident that she had no idea why the PSAT was important. She claimed that nobody had told her. We discussed a couple of questions she didn’t know and whether she guessed or skipped them. We asked if she knew which option was the best choice for the PSAT. She didn’t know.

This entire conversation frustrated me quite a bit, as I attended a session with her in the Spring about planning for college and some of the major milestones, including the PSATs. Additionally, for most of the summer I was reminding her that she had access to SAT practice tests and she should make the time to take them as her time becomes limited once school starts. At one point in the conversation, I realized she was right. Nobody had explicitly sat down and said the PSAT was important for x, y and z reasons. The importance was implied within broader conversations, but never explicitly stated.

It was easy for me to extrapolate this problem to project management as there have definitely been in situations where you were challenged with a request for less than solid reasoning, mostly because the other person didn’t understand why you were asking. We see this all the time in features and functionality delivered to spec, but that never at all meet the needs of the requestor. To the person doing the explaining, their why is fully ingrained in their own experiences. Each time he/she does this specific process, they have to execute these workarounds because the business need has outpaced the software development. The software developer sees the requirement for the new feature, and implements his interpretation of it. Unfortunately, the lack of understanding of the business needs and processes often result in a working feature that doesn’t fully resolve the business need (although it might replace the workaround).

Flexible development methodologies that allow for knowledge sharing, iterative review and feedback loops are helpful in minimizing this type of issue. As project managers and analysts, we need to hone our ability to ask “why?” not just “what?” Our documents and artifacts need to be flexible enough to articulate both, otherwise there’s a lot to be lost in translation.

Do you suffer from “fear of making mistakes”?

by

We often talk about “fear of missing out”, but I’ve found that “fear of making mistakes” is a much bigger issue in the workplace. I’ve worked with project teams where this fear of making mistakes resulted in in lack of communication and frustration on all sides. If we are not willing to make mistakes, how then do we learn and grow? How will we solve the complex problems?

Fear of making mistakes has significant impact to communication among team members. Those resources that are afraid to make mistakes tend to be less forthcoming with details and information. If only positive or complete information is shared, project management and team dynamics become very strained. As the project manager, I want to hear all of it. Help me understand the true status – what’s working, what isn’t, what the next steps are and how you anticipate the changes to the schedule. I’m not there as a passive participant. I am part of the project team, one that team members can rely on to help minimize issues, remove obstacles and ultimately celebrate success. I can’t do that effectively when members only share limited information.

Unfortunately this problem gets more complicated as time goes on. The resource is afraid of making a mistake, so withholds information. This leads to frustration on behalf of the project manager, who may be required to escalate. This makes the resource more nervous, so even less willing to share the low points. Without the proper communication, timeframes, effort and quality of work all come into play.

The onus of identifying this problem and mitigating the circumstances falls to the project manager. The project manager may need to set of separate touchpoints with the specific resource, and review the individual tasks. Targeted questions on next steps, and precise estimates will need to tracked very regularly. Additionally, feedback, especially on areas that aren’t working or need improvement, will need to be clearly documented. All this needs to be handled delicately as I found the resources who experience fear of making mistakes are usually working really hard. The lack of communication makes it difficult for the project team to see the results.

 

 

4 Lessons on Team Dynamics Learned from My Kids’ Sports

by

The start of fall rings in the season of multiple sports for our family. While I was protecting myself from the elements during the rainy, windy soccer game and then again, during the brisk temperature of the ice hockey rink, my mind drifted to the lessons we can learn from kids sports (or any sports for that matter). These lessons are also very applicable to any team endeavors including the team dynamics of managing a project.

You can’t control anyone other than yourselves

Teams, sports or project, are comprised of multiple people with very different and dynamic personalities. Each person is added to the team for their unique perspective and talents. It’s important to remember, both as a project member and team contributor, that you can only control your actions. If someone isn’t pulling their weight, or is doing something to negatively impact the project, you can try to influence them. However, the change in attitude or action can only be driven by the person doing it.

One option you have is to step up and fill a gap or try to positively offset the negative behavior. It won’t always work. In other cases it may be enough for the offending person to change their ways.

Sometimes external elements will adversely impact your performance

Outdoor sports are at the whim of the elements. While sometimes it is extreme enough to cancel or postpone the sporting event, but more often than not, the teams just have to power through it. In a project, there are also external pressures and decisions that will adversely impact your performance.

As a project manager, you need to do the best you can to minimize the impact. This might equate to sheltering your team with an umbrella or blanket. It is important to openly communicate about these challenges. As a team member, you need to trust that your project leaders will do their best to shield you from those external influences. Sometimes these efforts are not enough, and then you need to make do with the information and circumstance you have on hand. Like team players should never stop a play until the whistle is blown, team contributors should not stop working towards the end goal until directive is giving to stop or change direction.

You shouldn’t ignore those players who just show up everyday

My youngest daughter plays hockey primarily to spend time with her dad. She’s been playing for 2-3 years on a club team. Admittedly, soccer is not her favorite sport. She knows that playing a second sport often helps improve the first one. That all said, she goes to most practices, sometimes begrudgingly, and participates in all games where she isn’t already playing soccer. This does not mean that every waking hour is consumed by soccer either. It’s unusual for Ana to do an external practice.

This weekend was the first time this season I saw Ana play in both her soccer game and her hockey game. This year is the first year where Ana is playing on a full soccer field, so I wasn’t sure how she’d do. There’s a lot of running involved AND there’s an awful lot of opportunity to get distracted. She did well. Ana stayed focus, she didn’t get too far ahead of herself, or too far behind. The real drastic improvement was in her ice hockey game. This was the first game where I saw Ana as a real hockey player. She had a few shots on goals, plus a few assists. One was a beautiful play, where Ana actually looked up, acknowledged another player then passed the puck. Ana also had several breakaways to the puck, where she beat out the other players.

Something can definitely be said for showing up every day. You are going to improve a little  each time you get out there. Then one day, you will have actually made such significant improvement that everyone begins to notice.

You have to differentiate to separate yourself from the crowd

This one is somewhat in jest of the numerous Ana-like names on Ana’s soccer team. There’s Annika, Anna, Ana and Christiana, who prefers to go by “Ana.” We can’t use last name initial either as Ana is also, “Ana E” (as is Christiana). As you can imagine, this leads to some confusion about positions and field feedback. It’s easy to assume that it’s another  player receiving the feedback. This is not unlike a project team with multiple software developers, analysts or designers. External stakeholders do not necessarily understand the nuances of what each person is doing.

While most examples will not be as blatant as the 4 similarly named girls in the example above, you should assume that everyone is not educated about what you bring to the table. You will need to educate them. Whatever your primary strength, you should be highlighting this throughout your customer interaction. If your expertise is search engine optimization, demonstrating the techniques you use and their impact to the customer experience would differentiate you among your peers.

I’m sure there are quite a few other lessons we can learn from our extra-curricular activities. These were the ones that came to mind this weekend, with our specific games and circumstances.

 

Building Trust

by

Trust is a big component of successful project management. Team resources need to trust that each will will do what he/she has agreed to do, and will do it proficiently. The project owners trust the project manager to effectively manage all the resources, and ensure the project stays on schedule and on budget. The project manager needs to manage trust both up and down the project org structure. Without trust of the project owner, there is uncertainty about the goals, resources and schedule. And without some level of trust of the team resources, the project manager won’t be able to effectively communicate status or have any confidence that the work will get done. Unfortunately, trust is also an area that can be severely lacking in project dynamics.

Let’s first address the trust dynamic between the project manager and the project owner and stakeholders. The stakeholders are those people impacted by the project being delivered. The project owner should be the project’s advocate and supporter within the organization. Lack of trust can manifest itself in several different ways including:

  • stakeholders not trusting the project team to deliver the “right” business solution
  • stakeholders don’t trust that the project team will deliver on time
  • project owner is skeptical of the project success

As project manager, your ultimate success (of the project and within the organization) is dependent on how you manage these concerns. Trust is not something given lightly, it must be earned. If you are working with this project owner and stakeholders for the first time, or had the unfortunate situation of a prior project not going well, you will need to assume there are gaps in trust. Once you recognize this as a challenge, you can take the necessary steps to move forward. These should include:

  • understanding the business objectives and challenges the project is supposed to resolve.
    • ask to sit with the business users and share their problem. This deep understanding will help the team deliver the right solution.
  • as much communication as required by the project owner and stakeholders to make them feel included (and informed).
    • Ex: weekly email statuses or twice weekly status calls; or a couple of in depth show and tell sessions. It will really depend on the organization and the specific stakeholders.
    • communicating setbacks or challenges.  Do not shy away from sharing, or feel you need to hide the negative. Doing so will negatively impact project perception, and is counter to the trust you are trying to build.
  • using agile methodologies to deliver functionally ready project components iteratively through the project timeline that you can show the stakeholders.

Next up is the trust dynamic between the project team members (resources and project manager). Again, there can be many reasons why trust is non-existent within the team. Some include:

  • New project manager or team members that have never worked together before.
  • One or more team members have previously demonstrated some undesirable traits (ie. not delivering, not communicating delays, etc).

The team members do not have to like each other, although that can help. The project manager’s goal is to foster enough mutual respect to trust that the work will get done, and  the right project solution gets delivered to the stakeholders. A few methods for doing this include:

  • holding regular project touchbase calls.
    • these can be daily standups, or twice a week status calls. Figure out what works for you and your team.
  • having team members share information about external activities and families.
    • This helps team members see how similar they are, and lets them see the passion and interests that drives each of them.
  • providing time for peer programming or “cardboard batman” sessions.
    • By allowing the team members to help each other, they build deeper connections and foster trust. It makes the project a team effort, not just isolated, individual work.
  • Setting clear expectations, then verifying them.
    • It’s important to provide as much information as you have at the time you have it. Requirements are more fluid than we all care to admit, but making sure you pass new information on quickly will help with trust.
    • As project manager, do your best to verify the work delivered. This may be internal qa or show and tell with the stakeholders.
  • Acknowledging mistakes and promoting successes.
    • People want to do a good job. They also enjoy when those details gets shared within the organization. The project manager needs to take time to promote the team members.
    • Mistakes happen. They can significantly impact the project so they can’t be ignored. More important than the actual mistake is figuring out how to fix it. Acknowledge it, and then find a solution to get it remedied.

There are many different skills that make you an effective project manager. All of them are for not, if you can’t build the trust you need among the team. I challenge you to take a hard look at your projects and make sure you are taking the necessary steps to build the trust you need to make the project, and your team successful.

3 steps to take when your project isn’t going well

by

In an ideal world, all our projects are on-time and under budget. The reality is that is rarely the case. More often, a project runs over on budget or timeline. For the nature of this blog, I’m not going to go into all the reasons why there can be budget or timeline overages. I want to focus on techniques for managing the impact. These very much tie into my approach to project management (you can learn more in this post).

  1. Communicate – At the first sign of a problem, starting communicating up and down the project chain. You want to make sure the project team are aware of the additional stress and constraints the stakeholders are feeling. This keeps them moving towards the end, but prepares them for some of the more difficult conversations they may have with stakeholders. Also important is having an honest conversation with your stakeholders and business sponsors. You need to make sure that everyone is on the same page. It is not about point blame, but rather collectively determining the next steps and discussing remediation options. This might include reducing the scope, or increasing resources or budget.
  2. Be positive about your successes – When projects take a turn for the worst, it is easy to dwell on what’s going on, focusing solely on how to fix it. Make sure you are positive about the successes. These may be as simple as just developing the use cases, or maybe the team has started implementation and development. Each moment of time spent on the project increases the project outputs, and creates positive moments. Leverage these to keep morale up and keep stakeholders engaged with what has been accomplished. It helps if you’ve split your project into small, incremental releases. It’s harder, but still possible when your project has more nebulous intermittent releases.
  3. Keep team moving towards some release date – Project crunch mode is a very stressful time for all those involved. When those culminate, you will want the team to regroup to determine what can be delivered in the shortest amount of time. Ideally, this has some, if not all, of the functionality that is most critical to the business users. You are always better off if you get something in the hands of the business users, as quickly as you can.

Murphy’s law definitely exists in project management. If it can happen, it probably will at some point. I find that it’s much easier to manage these rough times if I communicate (almost to the point of over-communication), be positive about the small successes the team has and make sure we have a plan to deliver something. It helps if the things you deliver are aligned to the stakeholder’s critical requirements. Most importantly, do not shy away from talking about your project issues. That just builds resentment and further uncertainty.

My Approach to Project Management

by

A couple of weeks ago, the project sponsor of a project I’m working on sent a really nice note in reference to my work. It said “Dagny knows her stuff and I like her approach.” Since then I’ve been really thinking about my “approach.” I know that I’m good at what I do, and in this case, I’ve been given the flexibility to run these projects my way. But still, I wonder what defines my approach.

In the end, I’ve come up with 3 core principles to my approach.

  1.  Questions, Questions, Questions – It is critical in any project you manage to be willing and able to ask as many questions as you need. This starts before you even take on the project in it’s entirety. Who are my resources? Are they dedicated or part-time to the project? Next is the deep dive into any specifications or other project documentation. What are the goals? What is being requested by the customer? What do the resources think it means? What does the development landscape look at? All of these are just to get you started. Once you manage the projects, it is still your responsibility to ask and push. This is the only way to understand what’s going on. It is also the only way to can effectively keep the stakeholders up to date, as well as truly be able to remove roadblocks for the resources.
  2. Communication – Once you dive in and ask all these questions, it’s equally important to document the answers and communicate the impact. This applies as much (if not more) to negative information as positive. Do not shy away from delivering bad news. Knowledge in an of itself is worthless. You need to make sure you are effectively aggregating, documenting and then communicating the information you find. Make it available. Your forthrightness will be appreciated.
  3. Oversight – I believe you need to check in with your resources and your stakeholders on a regular basis. A regular cadence of status meetings is recommended, but I would strongly consider subsequent email statuses delivered between meetings, especially for time sensitive/critical projects.

I think these 3 principles are at the heart of my project management methodology. They result in not just effective management of a project, but also help to build the trust you need with resources and stakeholders.

Don’t take for granted how far you’ve come

by

I’m inspired to write this by my 16 year old daughter, who is also our summer intern. I’ve written about her before so I won’t spend too much time on background info. Cayla will start her junior year of high school in about two weeks, and this is Cayla’s first job. She agreed to do it because she had nothing else to do. My husband and I definitely had high hopes for her. Not only did we want her to start developing skills she would need after high school, we also hoped that she would start developing an interest in technology, aside from just personal use. She’s spent the last two months helping consolidate and organize our marketing list; started on Node School; and started learning R so she could work on her data science project to predict who will win the next Stanley Cup. Cayla also started pulling the data she needs for her project and working through her project plan.

Throughout all this, I’ve been amazed by the basic skills in business (and business applications), data management, and project management that I take for granted. There have been ample opportunities this summer for me to realize how far I’ve come since I started my first professional job.

Basic Skills in Business Applications – My experience is all very business and analytics intensive. As part of that, I’m very familiar with vlookups (using one data element in one spreadsheet to dynamically find the data element in another spreadsheet), pivot tables, advance sorting and grouping. While it made sense to make sure to teach Cayla how to do vlookups and pivot tables (as needed), it never crossed my mind that we would need to show her how to sort by multiple columns. Or, that she could use Excel functions to find duplicates, or convert names to the same format using the split text function plus a formula to reformat them. After the first time Cayla spent 5 hours adding the same value to multiple records by copying the cell and paste over and over again, it was very clear that I needed to be more explicit in the instructions and guidance I gave. These are basic lessons that I didn’t even realize everyone didn’t know.

Data Management – Cayla has been working with downloading, cleansing and analyzing NHL statistics for the last couple of weeks. We have had several discussions around computers being stupid and doing exactly you tell them to do. When the computer displays duplicate records, instead of grouping by a single identifier, I am quick to recognize that something is different about the records. Cayla was always more inclined to say that nothing was different as she was looking at the superficial value of the player name. Once she started diving into the data, she found spaces, tick marks and commas that wreaked havoc on her data analysis.

Project Management – I know that everyone works differently, but I’m a huge believer in documentation. I’m an avid notetaker, in my handy dandy hardcopy, spiral bound notebook. I red ink (and blue and green…) spec documents, log detailed questions and explanations and am quick to make sure everyone involved gets the information. I don’t believe in hoarding information. I assumed this was a way of life. It’s really not. No matter how many times I have coached Cayla about clearly documenting her project work, or outlining her blog post, this is not intuitive or comfortable to her. I’m a firm believer that developing these skills will help her feel more organized, help her remember or reference information better and would make communication in whatever form, easier for her.

Each of these are just a small subset of the examples I encountered this summer mentoring and leading Cayla. As we continue to mentor and sponsor people, we need to remember how far we have come. Let’s take a step back and make sure we convey the information required for people to learn the critical skills we have. They may not retain them all, but the good ones will definitely adapt some of those skills as their own.

Agile and #ILookLikeAnEngineer and the perception of things

by

I’m struck this week by the perception of things. This is not an unusual state for me as often I’m perceived as something different than what I am. My husband often tells people he is married to a West Indian woman. This creates some startling responses when those same people meet me for the first time. The general assumption is that I’m a black woman, so when they are presented with a blue eyed, blonde, very pale white woman, there is a bit of confusion. In addition, I am also 5’4 tall and average sized with an exercise of choice is Kempo (karate) and have earned my second degree black belt. Just another example of conflicting perception versus reality.

As a technical project manager, I am always interested in learning about new techniques and methodologies so like most of us, am familiar with Agile Development methodologies. It strikes me as interesting that many people and organizations will say “they do agile.” Agile is an adjective defined by Merriam Webster as “able to move quickly and easily” or ” having a quick resourceful and adaptable character.” How does one then “do agile?” I understand employing some specific components of agile methodologies, or working towards becoming agile. Organizations would be a whole lot better off if they stopped worrying about doing agile and actually started working towards becoming agile.

This week I was struck but yet another campaign about women in tech and what it means to be an engineer. These types of conversations always frustrate me a bit. I fully consider myself a women in technology, regardless of the fact that I’ve approached it from a business perspective. I’m raising two daughters, one who is very interested and one who doesn’t know she’s interested yet. “An engineer” or “to engineer” all relate to skillful or clever delivery of plans. While I will not minimize the effort it takes to obtain a engineering degree, the engineering mindset is definitely more than a degree.

I did participate in the #ILookLikeAnEngineer campaign, posting photos of both my daughters today. My youngest is very crafty, often coming up with elaborate stories for dolls and creating amazing worlds in Minecraft (parkour courses, stables with fancy armor, and star trek doors to her fancy chateaus). She also is learning to program so she can create games and websites on the topics she likes. We’ve been spending the summer tinkering with old laptops, assembling wooden model skulls and have plans for making cheese, soap, roominate assembly and arduino programming.

IMG_0175

As I have written about before, my older daughter sits on the periphery of STEM. While she has never expressed an interest in learning to program, or really anything mom and dad were doing. That said, when we proposed a summer internship working for her parents’ consulting company; learning about programming, social media (for business) and using “big data” techniques and software to predict who wins next year’s stanley cup, she accepted the challenge with open eyes.

IMG_0231

All of these are indicative of a larger problem. To make assumptions based on first impressions is harmful to us all. It is within our best interest to approach each situation with an open mind. Be observant; see what the reality looks like, hear what is being said, and then make your assessment.

Just take a stand!

by

For as long as I can remember, I’ve been willing to make a decision. The decisions I make are not life or death decisions. I guess this probably makes it easier for me. However, I would say that few people are truly in a position where there decision is going to make a difference between life or death. Yet, I continue to be surprised by people drag out decisions, even the ones that are seemingly insignificant.

Last week I was talking to an independent sales rep for a personal and professional retainer-based service. This service is applicable to many people and is very reasonably priced for individuals, families or small businesses. It also requires no contract, believing that the value of the service will become evident and you will continue on a month to month basis. The sales rep commented about how difficult a decision this was for people.

In another conversation yesterday, I was talking to someone who oversees a team of consultants and project managers. This team is managing a very large number of customers and projects, but often the senior manager has to step in to an escalation situation. For the many of these, he’s is simply reiterating the delivery message around when the work will be started and completed. It became evident in the conversation that the project managers were very hesitant to communicate bad news, or make decisions on prioritizations.

In my customer facing roles, this was never an issue. I understood enough about the business to make a decision, and communicate that decision to both customers and management. I often presented the decision I was going to make, with all the applicable ramifications to management and confirmed their support. I could then effectively manage the communication to the customer. If a customer pushed back on the message, I was able to re-evaluate and re-engage the internal resources to see if any adjustments could be made. At this point, it was helpful to have a senior manager along to show support for the decisions.

The inability to make a decision and move forward is something I see in my teenage daughters as well. For them I suspect it has more to do with confidence than anything else. It is definitely something we are working to take steps to overcome. We talk about decisions (good and bad) and propose other solutions that would have been better. We encourage them to write stories and make little decisions that impact their lives.

When you get presented with that next decision, take a stand. If you can articulate your reasoning when you need to, chances are it will turn out fine. If it turns out that your decision was the best one, then use that knowledge the next time you make a decision. You will only be able to make better decisions by making them. In the broader scheme of things, that one decision will not be significant.