Skip to main content

Author: Sean Lowe

The Feedback Six-pack

Written by Sean Lowe on . Posted in Articles. 4 Comments on The Feedback Six-pack

What would your response be when asked: “What is one of the most important and yet under-utilized project management tools?”

Would it help to mention that it costs virtually nothing, fosters team building, project communication and direction for your project team, and is something everyone seeks on every project? Projects Managers usually answer either a project schedule, risk management plan, or Earned Value as the most important under-utilized tool. These are indeed valuable tools but not the correct answer in this case.

Need more clues? How do team members realize the value of their performance? How do project managers realize the same? What sets precedents and expectations for future work and is the primary driver for performance improvement? It is feedback!

The Value of Feedback

Have you ever been curious about your performance? How many times has a vendor sent you a survey after selling you a product or performing a service for you? Good or bad, people enjoy knowing how they are performing.

Feedback is important because it provides the recipient with an opportunity to learn how the project manager (someone other than his immediate functional manager) perceives his work performance, which is often too specialized for the functional manager to provide constructive feedback.

Giving feedback to project team members during the project bridges the gap between feedback sessions that are held with their immediate management and provides a type of “compass” they can use for navigating through the project.

Feedback is also important because it fosters open communication with the project member. A by-product of providing this individual feedback is a demonstration to the recipient that trust and respect are essential elements of project team building. This encourages the recipient to give feedback to the project manager (after all, we all need performance feedback). This also gives the project manager the opportunity to demonstrate via behavioral modifications the effect of the team members’ feedback on her work.

Project managers should never think of feedback as a benefit to themselves; it is primarily about the recipient. Project managers will receive their return on investment when that person works for them again. If all project managers in the organization provide feedback correctly, at some point, all project managers will ultimately benefit.

Practitioners of feedback commonly claim that feedback holds a different value than does a gift or a raise. This, however, doesn’t at all mean that it is less useful as a motivation or reinforcement tool. In fact, feedback is not any less valuable, any less valid, or any less important than say, a raise.

Feedback Six-Pack

As a project manager, it is important to remember that the very act of giving feedback places lots of responsibility on the provider. The sole purpose of this powerful tool is to provide a supportive and timely perspective toward individual performance improvement.

Wise people ask key questions before beginning important tasks. So, before giving feedback, ask yourself these six important questions: who, what, when, where, why and how. This is the “Feedback Six-pack.”

  • Who am I giving this feedback to? To a close friend or to a colleague who I often conflict with? Remember that feedback can also be given vertically (management needs feedback, too!).
  • What kind of information am I about to communicate (good or bad)? What am I “really” trying to say? Stick to the facts.
  • When is the best time to catch her? When is she likely to be the least busy so that she can give me her full attention? When in doubt, schedule a 15-minute meeting with her. As a memory aid, consider using project milestones as a trigger that feedback is due.
  • Where is the best place to conduct this information exchange? Keep in mind that you want the person to be relaxed; choose a place accordingly.
  • Why am I doing this? It is crucial to never lose sight of this. Give someone feedback that’s bereft of sincerity, and you can expect it to be worth nothing.
  • How would I want this feedback given to me? Everyone is different, but sometimes knowing how you would like this kind of information presented to you could make a big difference in how you present it to others.

Timing is everything!

No matter what type of feedback you are planning to give, timing should be considered. Feedback should be provided timely, as close to the actual event as possible. Don’t wait! Remember, sincere people will not wait for a predetermined time to give feedback. This especially holds true when considering recognition; it should be paid on the spot, possibly in front of the team (if feedback in front of others is acceptable to the recipient).

Consider anchoring positive feedback to a positive mood. For example, don’t catch the person when he is in the middle of fighting a tremendous, highly visible, stress-creating fire, or you are drastically increasing the risk of it not being well received. At the same time, asking the receiver to describe the barriers that led to a critical deadline being missed is best done during a quiet time.

At the same time, if your project team members do not receive timely performance feedback regarding their efforts, there’s the risk that this could negatively impact your project’s (and, if compounded, your company’s) likelihood of success, which could foster lower morale and create a higher turnover.

Giving Feedback

The ways to give feedback range from formal or informal. In other words, it can be done in written form (formal) or verbal form (informal). Examples range from a comprehensive commendation written on company letterhead to a simple compliment in the cubicle aisles. No matter which method you use, though, be specific, be sincere and, most importantly, remember that the feedback is meant to help.

One risk Project Managers face is having our feedback come across as overly harsh or critical. We need to be supportive when giving feedback. This creates a more receptive atmosphere and increases the likelihood of more open and active information exchange.

We also need to ensure that our feedback is not distorted or misinterpreted. When speaking face to face or over the phone, a short recap of the recipient’s understanding of the feedback presented and any issues addressed during the session can accomplish this.

Just as you would do if you hired a DJ for your brother’s wedding, don’t judge people on just one event or one day of work. Everyone has a bad day occasionally. Give people the chance to show you that they are just having a bad day; allow them the opportunity to fix any mistakes.

Reviewing the “Feedback Six-pack” will greatly assist you in the structure and delivery of your feedback. This approach is low Risk and high yield. Remember that feedback should not be extra work, but as necessary work — and the professional responsibility of the project manager.

When I Grow Up, I Want to Be a Project Manager

Written by Sean Lowe on . Posted in Articles. 3 Comments on When I Grow Up, I Want to Be a Project Manager

I was sitting on a bench in the mall the other day bouncing my one-year-old daughter on my knee when a mother next to me asked her six-year-old daughter,

“what do you want to be when you grow up, sweetie?”

I remember thinking that this girl would most certainly rather play dolls and dress up than be presented with a question that many adults in professional careers may still be asking themselves. Perhaps the mother was looking for a few tips, I chuckled. I continued bouncing, awaiting the little girl’s answer. “A teacher,” the little girl returned along with a smile fit for a cereal box.

As a boy, I believe my favorite answer was Superman. My mom even made me a cape with a big “S” on it. Many of my childhood classmates wanted to be firefighters, policemen/women, and various other superheroes. I do not remember hearing “project manager.”

I decided to ask a group of sixth graders what they wanted to be when they grew up, and I received similar answers: firefighter, doctor, policewoman, construction worker, surgeon, etc. I then posed the following question: “What if you had to be ALL of these things every day? What would that be like?”

“Messy” was one boy’s answer. “I’d be all sweaty from running around putting out fires and then I’d have to get dirty building houses and all bloody cutting people up,” he said. “It would just be weird” was another girl’s response, “doing all of those things would get really confusing, and I’d probably kill somebody if I had to do surgery.” “I’d just try new stuff,” replied another boy, “because it might be cool to find out what it was like.” “That’s impossible” was the last boy’s answer. “How could you really be all of those things?”

Any of these humorous scenarios sound familiar? As project managers, we are expected to function in a myriad of capacities, including but not limited to firefighting, being the team/organizational policeman/woman, the contract and legal expert, teacher, coach, technical subject-matter expert (SME) . . . and the list goes on and on. We plan, schedule, obsess, coordinate, orchestrate, integrate, and see opportunity and possibility when others are calling for the project to be canceled. Super hero or not, however, we must resist the urge to “be” all things. A good project manager continues to develop professionally while allowing others on the project team to do the same. Delegation, empowerment and creative integration are instrumental in team development and, ultimately, project success.

The Project Manager as Firefighter, Law Enforcer and Doctor

Project managers own any and all firefighting that takes place within the “walls” of our respective project. It could also be argued that we must transcend these “walls” and extend our firefighting influence into fires that have the potential to spread into our “house.” In this respect, we are firefighters, risk managers, and problem-resolution experts. Risk management is an all too often neglected area that, when properly facilitated and integrated, can provide significant insight, context, and accountability.

Every call and meeting can provide an opportunity for anarchy. Rules, guidelines and “laws” must be placed within projects to keep traffic flowing in the proper direction. In terms of status and record keeping, it’s also necessary to closely monitor resource allocation percentages against limits (baseline). Just as traffic merges onto a busy highway, the project manager must police the integration of all project components.

Key project decisions are sometimes like prescribing medication or performing minor surgery. Decisions about what’s best for the overall health of the project are often times in the hands of the project “doctor” . . . and yes, patients die on the table. Good thing most project managers do not have to account for project malpractice insurance, or we’d all be singing the blues from time to time!

The Project Manager as Lawyer, Contract Administrator, Negotiator and Interpreter

Here’s where it starts to get really confusing. Depending on your propensity for legalese, contracts, statements of work, working agreements, service level arrangements and other business process-related documents may be on your project manager plate. Many times, the business arm of organizations frame and scope out efforts long before a project manager is engaged. This places the project manager “behind the eight ball” in terms of homework and diligence required to get up to speed on the contract and applicable deliverables, in order to appropriately validate the project scope and plan the integration of what’s to be delivered. The contract may be saying one thing, and the project may be headed in a direction to deliver something completely different. In this respect, we are the project’s lawyer, contract administrator and head negotiator.

The project manager needs to be able to take in information from all stakeholders (SMEs, vendors, multi-source providers, etc.), contextualize and prioritize it, and re-frame it for senior managers and other stakeholders — each of whom speak a different figurative (as well as often times, literal) language. The project manager also needs to understand how the cultures represented as stakeholders respond and react to information, how they’re motivated and more.

Information flowing down from top management needs to be cared for as well. Senior management’s communication vehicle to the project team is the “interpreter.” The interpreter also needs to internalize, translate, consolidate and subsequently communicate key stakeholders’ respective interpretations of project success.

The function of the project manager is to be adept at the multiple roles required to be project manager — not to be a SME on a specific task or, as is more often the case, the product or technology the project is delivering. We must be a translator, law enforcer, firefighter, lawyer, politician, superhero, doctor and, yes, “seer of the future.” Organizational SMEs may be well equipped to complete specific project tasks, but not to manage the integration of all project components.

Project managers must fill many roles, every day and it does get weird, messy, dirty, confusing and, if you’re having a really bad day, seemingly impossible. But, it’s really “cool” when you realize that it is possible for one person to manage the integration of “all of those things.”

Information Security Project Management

Written by Sean Lowe on . Posted in Articles. 6 Comments on Information Security Project Management

Certainly no profession is recession-proof, but the abundance of IT and information asset protection needs are creating many opportunities for project managers willing and able to undertake and deliver information security projects.

The worlds of information access and information security are inextricably joined, and as such, data must be readily available and accessible to all who need it, yet its confidentiality and integrity simultaneously maintained. As project managers, we have all managed technical change, but the current pace of technological advancements, coupled with an influx of increasingly sophisticated security threats and attacks, as well as the need to comply with a myriad of privacy laws and security protection standards, all but guarantee heightened interaction and benefits to partnering with our local information security group.

Who are these security folks and how do they operate? Simply stated, the role of information security is to balance risk and value toward enablement of the business. Security practitioners understand and communicate risks and provide solutions within the context of business value-creation. Solutions are chosen that reduce risk, and may include any number of security initiatives such as: creating isolated networks to protect critical data, installing intrusion prevention devices, logging and monitoring security events, or achieving compliance with security standards.

Related Article: Diffusing Organizational Risk

Information security groups also exist to provide education and awareness regarding company security policies and procedures while performing real-time threat monitoring and remediation.

Here are four critical areas to focus on and remember when assigned your next Information Security Project:

1. Secure executive sponsorship and formal backing. Executive leadership must be onboard with, scope, objectives, and strategic fit

Involvement and backing from the CSO or senior security leadership as well as the publicized alignment with strategic company initiatives demonstrate to users at large that the project or security initiative is not simply another “nice to have.” This is also particularly important because your project may require folks to participate in security training or to complete a security specific task. In many cases, having ongoing senior leadership support and backing will be your saving grace.

Executive leadership on information security projects is particularly important because the company’s competitive advantage is based largely on ensuring that critical data is protected and accessible. Once leadership acknowledges and embraces this, these projects are no longer viewed as straight costs, but investments in creating and enabling trusted, manageable and scalable information protection and access. While you have the Sponsor’s attention, ask for insight into the overall IT security plan (or strategy). This will provide additional clarification and focus as to the role your project plays in the grand scheme. Also, take this opportunity to learn what you can regarding key resources assigned to your project.

2. Know your Security solution(s)

Researching the security solution to be implemented will not only provide the context necessary for a deeper understanding of matters at hand but demonstrate to your team and stakeholders that you’re invested and success-minded. This diligence should also extend to any contractual agreements and internal working agreements. Without this knowledge, you may face trust issues with the client, as well as an increased lag in overall resolution as they will expect the project manager to be able to handle most issues and questions. Deeper functional understanding may also provide insights into associated operational security projects. To be effective, IT security must be operationalized, and the very best way to get there is through integrated and well-managed projects.

3. Establish a common Risk Management approach

The generally accepted information security approach to risk varies slightly from the standard project management approach. While specific risk events, their probability, and associated impact ring true to project managers, security practitioners tend to think in terms of threats and the possibility of these being exploited to expose particular vulnerabilities. With this method, business assets are typically assigned a value, in order that the threat, and vulnerability, if exposed, can be quantified. Given the slightly different approach to risk management, it will be beneficial to meet as close to project inception as possible to develop a common approach to identifying, documenting, and managing overall risk. This will establish a solid foundation for the often semi-uncomfortable risk discussions and pave the road for necessary assignments and follow-ons.

4. Know your Project Team, Vendors, and Subcontractors

Never underestimate the importance of collaborative planning and communication. The closer the team, the more productive the collaboration and communication can be. Attempt a one-on–one meeting with each team member, vendor or sub-contractor in advance to discuss their role, specific areas of expertise and to air out questions and concerns in a non-threatening environment. This will pave the road for knowledge and experience sharing going forward. During the kickoff meeting, encourage open discussion of individual roles and input items to clarify further each party’s interests in and commitment to the project.

Solid executive backing, knowledge of the solution(s) under consideration, a common and agreed upon risk approach and knowledge of team and vendor relationships will greatly increase the chances of your next information security project being a smashing success.

Diffusing Organizational Risk

Written by Sean Lowe on . Posted in Articles. 4 Comments on Diffusing Organizational Risk

As project managers and leaders we face many internal and external factors that influence our project’s success, and must mitigate or eliminate uncertainty as it relates to any factor’s contribution(s) to any element of project failure.

Unfortunately, the PM’s path to success in this endeavor is riddled with a large number of “land mines”. While some of these are easily avoidable, others are a bit more cumbersome and rooted in management structure, company policy, ignorance and corporate politics, or some combination thereof.

With proper training and careful navigation, it is sometimes possible to diffuse these. 

Below are seven “mines” to avoid (and tips for diffusing them) as you take the field of battle to your next project. 

1.Lack of Risk Management Education 

Unfortunately, you are likely the most educated person on your team in the field of Risk Management. This means that your sponsor and stakeholders likely do not have the same view of the strategic importance or management execution process. While some might argue that this is to be expected, having team members and management that are educated in basic risk management principles makes your job inordinately easier. Educated  sponsors will likely secure more funding for risk-related activities, and will certainly be more tolerant of the time that the team needs to spend working through identification, documentation, follow on, and so on. Team members with a basic understanding of risk management process elements will more fully understand and appreciate your role and struggle. 

{module ad 300×100 Large mobile}

Tip-> Suggest cost-effective security awareness items related to the risk management process to your senior leadership. Partner with your internal audit team or risk organization (if blessed with these) to present this. If successful in this step, navigating and diffusing each of the subsequently mentioned “mines” will be much more tolerable.

2.Unclear Risk Information

Basic IT project risk management usually entails working with the team to understand and capture risk and opportunity events. This can sometimes be a tedious process unless you’re blessed with co-location and the team’s undivided attention. In  the case of a distributed team, the PM often receives risks written as broad and open statements or other indistinguishable blurbs.  Taking the time to educate the team on the importance of creating individual and distinct “risk events,” with the goal of determining a specific and actionable strategy can be somewhat time-consuming.

Tip->Create a template with “call-outs” that spell out exactly what is needed for each section of your risk register, chart or heat map. Make time to discuss this with your team.

3.Lack of Organizational Drive

As mentioned earlier, you may be the Lone Ranger when it comes to driving the need for risk management on your project or program. If you are able to promote sound risk management practices and to educate folks, you may be the catalyst needed to get something meaningful initiated within your company. Practicing consistent Risk Management as part of your normal PM repertoire will strengthen 

Tip-> Use this opportunity to strengthen your personal “Brand” (link to PM Times article on personal branding http://www.projecttimes.com/articles/project-manager-personal-branding.html)

4. Once and Done  

It’s simply not enough to conduct a one-time session to identify risks, determine their probability, impact and response strategy. Someone needs to monitor each risk continually to determine changes to its probability and overall impact. This is particularly true in cases where the subsequent project requires completion of specific deliverables to enable the successor project to initiate.

Ownership and accountability need to be distributed across the project team and not just be the responsibility of the project manager. Creating an atmosphere of risk ownership and accountability is a necessary step in organizational risk awareness and evolution. Individual risk events identified must have individual owners. Risk-evolved companies do not rely on siloed heroics but on more integrated, strategic and proactive measures. Communicate to the team where the project fits, where it’s headed and ask them about opportunities that may be capitalized on as well.

Tip->Use this as an opportunity to reference and utilize the aforementioned risk register.

5. Disruptive, waste of time and resource cycles

Management’s prevailing view may, in fact, be that risk exercises are a waste of time and resource dollars.

Tip->Make a personal commitment to demonstrate ROI via presenting management with examples of cost and time savings via “team identified” mitigation strategies.

6. Lack of historical risk data 

Many organizations that perform Risk Assessments do not have a stable and mature historical archive of risk information to draw from. This may well be because these types of exercises have not been historically conducted, or that efforts to archive Risk data and information has been inconsistently performed.

Tip -> Partner with your internal Audit Team/department or Risk organization to initiate an archive.

7. Flawed evaluation of effectiveness

What are the measures of success for the Risk Program and Risk management activities in general for the company? Chances are, there are none! If in its infancy, chances are program success has but one criteria for success, and that is adherence to corporate policy. If the policy states that a risk assessment needs to occur once a year and it does,  that is the sole measure of success!

Tip ->Work to have the definition of Risk success tied to the program’s effectiveness in achieving company goals. Initiatives and projects are aligned with Corporate Strategy. Successful initiatives and projects then, enable the realization of Corporate Strategy. Effective Risk Management enables the planning, delivery and execution of the strategically aligned initiatives and projects.

How Confident are You?

Written by Sean Lowe on . Posted in Articles. 3 Comments on How Confident are You?

Choose your company or project … I’ll even go out on a limb and say that it really doesn’t matter the size or scope of the initiative … The story is always the same …

There is work to be done that is not fully understood by management, who wants it done yesterday.

The groups in the trenches performing the work are asked “when it will be done.” This usually entails detailing plans, or in many cases simply communicating a “completion date.”

This date is then adopted by middle management as a promise and communicated as such to the upper echelons of the company.

All of the schedule risk is then bore by the workers in the trenches who communicated the completion date.

As far as middle management is concerned, so long as the date was not accompanied by assumptions, constraints and stipulations, it does in fact represent a promise of 100% completion, on and by said date.

What’s wrong with this picture? Why is this pattern so prevalent and pervasive?

The good news is that there is a relatively simple and highly effective tool that the “folks in the trenches” can use to greatly reduce the amount of schedule risk borne, while facilitating needed communication with management.

This tool is a LOC, or “Level of Confidence” indicator.

Let’s rewind our story to the beginning (Rewind sound …)

  • There is work to be done that is not fully understood by management, who wants it done yesterday.
  • The groups in the trenches performing the work are asked “when it will be done.
  • A completion date is communicated … along with a 50% associated Level of Confidence. Management’s brow furrows … What’s this Level of Confidence percentage, they ask? It is then explained that the 50% LOC was provided as management needed a date right away, and the delivery team is not prepared to present a date that they are 100% “confident” in standing behind.
  • Fifty percent LOC represents that the team is 50% confident and that the estimate could vary an additional 50%. The next round of questions and answers is priceless, and makes the whole exercise worthwhile.

Mgt – Why are you only 50% confident? Do you have the right resources involved in this project?
Deliv – Yes, the appropriate resources are being engaged and we’ve already been through a good deal of application testing. We still need to test X# of additional components that directly affect (the following top clients)multiple parties. Not doing so could be catastrophic!
Mgt – OK, how long will that take?
Deliv – We are working diligently to determine this and will adjust our LOC % for the next status report.
Mgt – What else do you need to increase your LOC %
Deliv – Well, if we had two more top developers fully engaged, we could speed things along nicely …

The point here is that none of the communication transpiring would not be taking place had the Level of confidence percentage not been part of the communication.

Capturing Level of Confidence facilitates realization of benefits across multiple stakeholder and the project overall … as well as:

  1. Allows those communicating completion dates to bear “Less Schedule Risk.”
  2. Causes “Shame reporting” for those falling behind and “Horse Races” for those in the lead (on projects with multiple teams).
  3. Drives out reasons for low levels of confidence and helps drive communication around solutions to mitigate schedule Risk,.
  4. Increases management awareness/visibility/understanding of challenges and roadblocks.

You’ll soon be asked for dates … How confident are you?

Don’t forget to leave your comments below.