Category Archives: Project Communication

How a Culture of Accountability Impacts Solution Delivery

  By | , , ,
Leave a comment

Recently I have been thinking about how leadership and culture plays an essential role in our ability to deliver quality solutions.  More importantly how accountability will have a direct impact on our ability to help team members stay engaged and empowered to produce positive results.

There are different accountability chains based on the alignment of project resources.  Specifically, when you look at matrix project reporting structures vs functional project reporting structures you will have different layers of accountability.  The type of project organization structure has a direct impact on the project leader’s ability to influence or drive accountability.

When you do not have a culture of accountability in your organization you will have some of these resultative behaviors:

  1. Morale issues – top performers tend to disengage.
  2. Siloed behavior – you will hear “well my resource manager told me to do this” specifically observed in a matrix organizational structure.
  3. Rescuer behavior – because the person believes they must make up for others not performing their respective roles on the project.
  4. Active disengagement – because the team do not feel empowered to hold each other accountable for results.

From my experience on leading projects in both matrix and functional project structures I have found that it is critical that the project and program leader focus on these key qualities to embed accountability in your solution delivery practices.  This is not an all-inclusive list but rather some key focus areas to drive:

  1. Goal setting – set clear expectations up front and inform the team how they have influence in the team’s ability to be successful by clearly defining what success means.
  2. Empowerment – reinforce with your team that there will be mistakes, and if we as a team own our mistakes, learn from them we will move on and be better for it. This safe environment approach will help your team members embrace their empowerment.
  3. Process adherence – with clearly defined delivery processes established the team have a roadmap on how the overall solution will be delivered.
  4. Encourage continuous improvement – as a leader you need to encourage the team to bring their thoughts and ideas on how to enhance or change processes for better outcomes moving forward.
  5. Team accountability – the team need to understand the goals of the delivery and then hold each other accountable.
  6. Measuring success – the team need to understand how their performance will be measured and how their respective inputs align with the overall delivery success.
  7. Celebrate success – recognition and success are key motivating factors for your team. It cannot be underestimated the major benefits of team morale in simply recognizing key success milestones and as a team celebrating.
  8. Tools and transparency – collaboration and document management tools are essential for your team’s ability to communicate and share key information throughout the delivery. Setting these up early in the delivery cycle and then validating that they are effectively being used is a critical aspect not to be underestimated.

In closing, project and program leaders play a critical role in how accountability drives quality solutions.  Understanding your corporate culture and how you can lead your teams through solution delivery by reinforcing accountability through the solution delivery will lead to successful delivery solutions and help drive your company closer to a culture of accountability.

Lessons on Right-Sizing Project Management

  By | , ,
Leave a comment

In my previous article “Progress Your Project with Processes” I discussed the need to incorporate processes in your project management solution delivery. In this article I would like to delve in to the need to right-size your processes for your project delivery.

Most stakeholders feel that your project management processes are too heavy regardless of how much effort is expended in right-sizing them. I have heard this assertion on at least one occasion from an outside consultant, however when project execution was underway it was determined that the processes in place helped ensure that the delivery team understood the complexity of the effort and were empowered to deliver on their respective activities.

The main reason for this empowerment is because there was effective planning and communication at the beginning of the delivery and as a leader I was able to articulate the direction we as a team were embarking on. Stakeholder analysis up front and continued assessment are also key factors.

The complexity of your project needs to be considered along with the delivery methodology you intend to utilize. The more complex your project the more you need to rely on formal project management techniques.

I have found that there are three essential steps in determining how to right-size your project processes.

  1. Identify your delivery needs
  2. Select the tools to be used for delivery
  3. Adjust as you go

1.  Identify your delivery needs
When identifying your delivery needs it is important to first decide on the software development life cycle (SDLC) methodology your project will be utilizing. The methodology in and of itself is not the key, but rather assessing the specific approach you will be taking and subsequently determining the impact of the methodology on your stakeholders are the keys. If your team is new to a specific methodology, then steps need to be taken up front to take them on the learning journey while continually communicating expectations throughout the delivery cycles. You may also find when reviewing your SDLC that adjustments need to be made to the methodology to better clarify the tools and techniques that will foster solid delivery. Some questions you need to think about should center around; is there an effective communication plan, is change management understood, how will the team be empowered to report activities, risks and issues, and how will lessons learned be gathered throughout to support reassessment.

2. Select the tools to be used for delivery
Selection of the tools may be driven by what is available within your company. I have found there are three main tool areas that need to be accounted for. These three areas relate to content management, development management, and test management. Content management would be the tool used for gathering and maintaining project specific documentation. As an example, you may find that it is easier to use a simple tool for managing actions, risks, issues, and decisions such as an Excel workbook, or in a more complex delivery you may want to track these items utilizing a formal content management tool and workflow. This is an area that should be right-sized based on the complexity of your project. If you are delivering using an Agile methodology you will want a development management tool that will support your product backlog grooming and the velocity tracking of your team such as Jira, Version One, or Rally. If you have a separate tool for managing test planning and execution it is important to guide your team through which tool will be used for communication management. For instance, defects may be captured in the test tool but communication with the development team may be captured in the development management tool.

3. Adjust as you go
Retrospectives and lessons learned activities are not only important for how your team works together, but also relevant for what processes need to be modified as you progress through your delivery efforts. If managing through a waterfall or iterative waterfall SDLC, at a minimum you will want to hold a formal lessons learned at each phase gate. If managing utilizing an Agile SDLC, you should ask your team to think about processes when completing their retrospective activities and support any suggestions they may have to update processes accordingly.

In summary, it is important to assess up front the appropriate project management processes that will be used to deliver the solution. In doing so you need to account for the complexity of the project and the communication mechanisms that are required. The tools you choose should support the activities to empower your project team to be self-organizing and you need to adjust as you progress through project delivery. Remember as always to have fun!

5Ws & 2Hs for Planning Project Kick-off Meetings

  By | , ,
Leave a comment

Typically after a project manager is assigned to a project it is customary to hold a project kick-off meeting. When planning for a kick-off meeting it is essential that the project manager approach the planning as a must do activity needed to support the successful delivery of the solution. When approaching your kick-off planning you should be thinking about how to “right-size” the kick-off relative to the size of the project that you have been assigned. While you do not want to diminish the excitement that you hope to generate, you need to ensure that the length of the meeting is appropriate to the size of effort.

There are some key attributes that are essential for a project manager to be successful, and these attributes will need to be leveraged to plan and execute the kick-off. These key attributes include but are not limited to being an effective leader as well as having the ability to communicate effectively. You will also want to make sure that you approach the kick-off striving to achieve the tone you will be setting for your project, so do not underestimate the need to have fun and to keep the meeting upbeat.

I harken back to when I was in school and learned the 5 Ws and 2 Hs, so here are the areas I consider when preparing for my kick-off meeting:

  1. Vision (why)
  2. Success Criteria (how much)
  3. Scope (what)
    1. Dependencies & Constraints
    2. Assumptions
    3. Risks & Issues
    4. Communication Plan
  4. Stakeholder Analysis/Assignments (who)
  5. Schedule (when)
  6. Methodology (how)
  7. Logistics (where)

Based on the size of the project you will need to decide which of these areas require more focus or planning, but I would highly recommend that each of these are touched on and reviewed with your team. These are not in any priority order, but more of a logical listing based on my previous experience.

  1. Vision (why)
    Provide the business sponsor’s view of the desired outcomes to be produced for the business after successfully completing the project. The description should reflect what the business will be like to inspire the project team at kick-off. You could include some of the benefits used at project initiation to drive the business case development.
  2. Success Criteria (how much)
    It is important to start your project team thinking about success criteria at the beginning of the project. The easy definition of success criteria would be the standards that the project will be judged at delivery to decide whether or not it has been successful in the eyes of the stakeholders. The business sponsor should have defined the project success criteria when building the business case and these criteria should be the drivers for acceptance criteria for your requirements and overall solution delivery guideposts throughout the lifecycle of the project.
  3. Scope (what)
    Providing the boundaries of the project including what will and will not be part of the delivery effort is important at this stage. This information will be used as guidelines for making decisions about change management in future stages of the project.

    1. Dependencies & Constraints
      You may not understand all your project dependencies at this point, but at a minimum you will understand if there are other project or programs that you are dependent on, and if you have any constraints (limits) that need to be highlighted for your team.
    2. Assumptions
      As assumptions are identified, each must be viewed with an appropriate degree of skepticism. I set a tone up front that we need to limit our assumptions and that assumptions should not be wishful thinking. I can pontificate here on how assumptions have turned out to be extremely costly for my projects in the past, but I will save that for another article.
    3. Risks & Issues
      When presenting your risks to the project team make sure and include the risk management strategy you plan to incorporate for each risk. The team should be encouraged to actively identify risks and risk mitigation steps throughout the project lifecycle as this should not be a project manager only responsibility. If risk management is effective then issue management becomes easier.
    4. Communication Plan
      Having a communication plan in place is an essential component for good project management. Depending on the size of the project your plan could be a simple table reflecting the type and timing for meetings, status reports, and other communication mediums, or a document clearly articulating all aspects of a formal communication plan.
  4. Stakeholder Analysis/Assignments (who)
    Identifying the individuals or groups that are likely to affect or be affected by the project, and understanding them according to their impact is an essential step in kick-off planning. Being able to articulate to the team how each stakeholder will be impacted and if they are a part of the project team what their specific role will be is critical.
  5. Schedule (when)
    The schedule at this point would be a very high level of milestones, activities, and deliverables that were identified to build the business case and leverages the internal SDLC framework. It is important to help the team understand that you will be working with the team to help build out a more detailed delivery schedule moving forward.
  6. Methodology (how)
    Your team needs to understand what methodology the delivery will follow. Any stage gates that are important and what those gates mean as a team. You may find that additional training may be required for team members if they are new to the project methodology you will be using.
  7. Logistics (where)
    Your team should understand where the main project activities will be located, and if you have remote project team members they will need to understand what mechanism will be used to connect.

In summary, it is important to take sufficient time to plan for and then hold a project kick-off meeting. The kick-off should be “right-sized” based on your project size. You will be required to use key project leadership and communication skills to ensure that you set the right tone up front with your project team. Remember to have fun!

Apply Care for Program Success

  By | , , ,
Leave a comment

As my current program moves into another sprint retrospective tomorrow I have been reflecting on some of the learnings I have been able to successfully incorporate in my day to day approach to the program and project management areas during the full solution delivery process. While there is not a one size fits all nor a magic bullet on what it takes to successfully deliver IT solutions there are some key theme areas that should be reconsidered periodically. This is not an all-inclusive list, and these are not in any priority order.

Building Real Accountability – Do the program team members exhibit behaviors that highlight ownership and engagement? One of the easiest ways to ascertain this is when you see people step forward after a mistake is made, own it, learn from it, and we can move on. Once your team feel safe that it is ok to be wrong they tend to be more apt to try new and innovative ideas.

Resolving Pernicious Problems – Are problem areas being raised to the right level and are they being resolved timely? If you have fostered an environment on your program where every stakeholder has a mechanism to report and support risk and issue management this becomes a continuous activity. The project management team should not have all the onus to document and manage risks and issues. By providing the tools and the expectation that this is part of the day to day team activity you will see more transparency in the internal workings on the program.

Creating Effective Plans – Has enough attention been paid to the planning processes? There is an art to planning a program. Identifying the work that needs to be completed, and supporting the internal processes that are built to ensure quality deliveries are sometimes elusive. The tendency is gloss over the importance of stakeholder analysis, activity dependency identification, and resource capacity planning. If these are not done well and continuously managed you could find yourself with a perpetual end date.

Reflecting Upon Leadership – Have you spent enough time thinking about your role as a leader and how you are affecting the outcomes? Each of us have our own leadership style. There are a multitude of factors that need to be considered based on our own comfort zones and the environment/culture we are leading in. For instance, you do not want to over use an authoritative style in a highly collaborative culture. Make sure and take the time to understand your own style and how that style can be leveraged in the corporate and team cultures you are delivering in.

Yenning Informed Thinking – Do enough team members consider the big picture, or is the big picture thinking happening at the top? Not everyone has the ability or experience to think both strategically as well as tactically. To ensure that the strategic thinking does not only come from the top you should work to identify key team members that have this ability and encourage them to participate in the overall planning efforts. Tactical thinking is made easier by process management.

Recognizing Beneficial Celebration – Are you taking the time to appreciate successes and celebrate key milestone achievements? We spend a great deal of our time at work, and most people have a need to be shown that this time away from their family and friends is worth more than a paycheck. It is important to recognize individuals for their successes. It is equally important to understand how your team members like to be recognized. You do not want to publically recognize an individual if they would prefer to be recognized privately. It is also very important to stop and celebrate key milestone achievements. This is an opportunity for the team to step away from the grind of the day to day and recognize each other for the commitment to the continued success of the program.

Supporting Avuncular Behavior – Do you have mentoring behavior on the team? It is important as you build your team to recognize where more experienced professionals could support more junior team members. Either by establishing a formal mentoring relationship or pairing key program activities up to support the transfer of knowledge and experience. It is not always easy to identify individuals that are willing to impart their wisdom with others, but once you find those that are willing and effective your program and project team will reap the benefits.

Evangelizing Solid Resources – Are there key tools in place to support content management, planning and execution, and defect management? You will want to make sure at the beginning of the program that you take the time to identify what tool will be used for what purpose. Once this is done you will want to ensure that all the team members are educated during the kick-off and subsequent on-boarding activities about what each of these tools represent and are used for. This will cut down on the amount of noise created by missing or misunderstood information.

Cultivating Sound Environment – Does the team culture align with the corporate guiding principles? Each organization comes with a defined culture and with that culture are focused leadership competencies and behaviors. It is important to take stalk and recognize what these are and ensure that you are consistently leading by example. If you are hearing the statement “this is the way we do things around here” you will want to spend time to understand at the core what is driving these statements and what you can do as a leader to either foster or dissuade the behavior.

In conclusion, there are a multitude of areas to ponder when you approach solution delivery and these are just a few that I have found helpful in achieving my program delivery successes. Many of these come through the hard knocks of the project management profession, so I would encourage you to APPLY CARE!

Progress Your Project with Processes

  By | , ,
Leave a comment

Processes benefit projects. Effective processes enable efficient communications, foster collaboration between teams, and maintain consistent project controls. Most importantly, processes can push through brick walls that block your project’s progress!

I have used the idiom “progress your project with processes” quite often in my career. I originally used this term to help my team understand that if the project and resource management processes on our program are effective then these processes could and should be used to resolve conflict. These processes should also be used as guiding principles for the way the team interacts with one another. Processes will, in essence, take the emotion out of decision making when faced with hard decisions.

Project managers spend a great deal of time at the beginning of a project to ensure that the Project Management Office (PMO) processes are clearly established with their project teams. However, as most of us know, the PMO processes only take you so far. There is a fair amount of process definition that needs to be completed for each project based on a multitude of factors. These factors include culture, resource location, project size, regulatory requirements, and other similar characteristics.

One common “brick wall” is change and change management. If you have done a good job of determining the change management process up front, then effectively using that process to manage through ideation to completion can help resolve many conflicts on a project. In other words, if what is change and what isn’t change has been defined up front, then this is your guidepost when faced with change requests. You will be able to take the human conflict out of the equation and instead focus on working through the impacts by following your processes.

Another area is schedule management. As a project manager, it is extremely important to establish a schedule that focuses on both the methodology and related deliverables—as well as the actual deliverables needed to meet the project’s objectives. When the initial schedule is built, you will be working with the stakeholders on your team to determine their work packets and any dependencies they articulate. Once your resource capacity and leveling has been established in your schedule, you can then use this structure to clearly outline any future impediments when scheduling conflicts occur based on slippage in those deliverables. You will be able to rely on the process to help you articulate the problem and guide you in fostering a resolution.

There may be a perception in some organizations that processes are overused or overrated. In other words, there is a diminished value perceived from process management. This perception typically appears in start-up or small companies that have to be agile and react quickly to changing market demands. But, even for these organizations you can right-size the processes to ensure limited rework and still maintain solid delivery cycles. You may also observe this perception in large organizations. It is the project manager’s responsibility to define up front the processes that will and will not work given the environmental factors. This approach will help with the “too many processes” perception in these organizations.

In conclusion, design effective processes up front and use them to push through the brick walls that block your progress!

A special thank you to Jerry Johns for acting as my editor on this article!

Overcoming Communication Barriers

  By |
Leave a comment
Barriers

Communication

Today I went out to get some exercise by running to pick up a few things at a local store.  Many times on my runs, I am able to open my mind and ponder over life and work problems.  During this particular six mile run, I was stopped by a young lady in a car.  When she caught my attention, she waved me to her car.  Upon approaching, she made it clear that she was mute.  She was highly agitated but I waited to see what she was going to do next.  She pulled out her iPhone and opened a web page that had a store address on it; she was obviously lost.  This store was next to where I was headed.  I thought “no problem” and proceeded to give her directions.  She stopped me and motioned that she was also deaf.

I immediately switched to panic mode and thought:

  1. How am I going to help this poor lady?
  2. I looked in her car (which was very clean and new) and wondered if I should offer to ride with her to the store:
    1. Was I willing to take the risk that she was a serial killer trying to get me into her car? No!
    2. Was there a pen and paper visible that I could write the directions on? No!
  3. Could I speak slowly and use my hands to direct her to the store? Perhaps, but I do not know sign language!

Taking a gamble on the latter, I slowly talked her through the turns while pointing to the road ahead.  Luckily, there were only two turns to get to the store.  She used her hands and repeated what I had shown her. She thanked me with sign language (I do know that sign) and was off.  The good news is that when I reached my destination, her car was in the parking lot.

I started thinking on the way back from the store about the many communication barriers project managers often face on a project.  For example:

  1. Language differences
  2. Co-location of project team members
  3. TAWAU (The acronyms we all use)
  4. Cultural differences
  5. Psychological drivers
  6. Barriers caused by varying perceptions of reality
  7. Barriers caused by differing levels of understanding and comprehension

This experience made me think about the importance of breaking down communication barriers on projects.  I like to believe that I positively impacted that young lady’s day by finding a way to communicate with her.  It is the responsibility of any project manager to adjust how we communicate by understanding the needs of our audience. I often say that “understanding” is the first step for “improving.”

Language Differences
Trying to communicate with someone that is deaf or mute is difficult.  Another example is working with someone that does not share your first language.  I have struggled with understanding people whose first language is not English.  When faced with this barrier, you may have to communicate in writing or use images to facilitate better communication.

Co-Location of Project Team Members
When working on projects that have team members in different locations, it is very hard to pick up on the non-verbal forms of communication.  Consider how much information we convey with a smile or a frown.  When you are on conference calls, you miss out on this important form of non-verbal communication.  My suggestion is to use video conferencing where possible to convey this non-verbal feedback.

The Use of Acronyms
You should stop and take count of how many times a day you or someone on your team uses acronyms.  If someone new joins the team this could really be an obstacle if your corporate culture is driven by the use of acronyms.  You could create a “cheat sheet” as a project tool that could be used to help new team members transition on the team more easily.

Cultural Differences
I work for a company based in Ireland.  I joined this company after spending most of my career working for US-based organizations.  One of the biggest lessons I learned about the Irish was that using surnames to address them is in very poor taste.  I was only told this after being with the company a year while out at a pub.  Imagine my embarrassment when I thought back to all the times I had done this on calls and in person.  In my mind it was easier to use surnames and common in previous companies I worked for when addressing individuals on calls that shared the same first name.  Now that I have learned this I try to address team members by their first name and first initial of their last name.  I would encourage you to understand cultural differences when you work on projects that have project team members in other areas of the world.

Psychological Drivers
You can learn a lot about project team members during the course of a project.  What motivates these individuals is very important to know.  One of the best examples is recognition.  I am motivated by doing a good job and being recognized for the hard work needed to achieve positive results.  I do not mind how this recognition is given; it could be verbal 1×1, verbal in a team setting, email, or corporate reward structure.  There are team members that cringe at the thought of being publicly recognized and are not motivated by recognition.  They may be motivated by time off in lieu, money, or many other factors.  It is important to understand what motivates your team members so that you do not accidentally use a form of recognition with them that is unwelcome.

Barriers Caused by Varying Perceptions of Reality
All of us synthesize our decisions through a lens of past experiences.  Depending on our experience level and the environment in which we grew up or currently live, our decision making processes are quite different.  There have been times that I struggled with understanding why someone could not move past a specific issue.  It was not clear until they let me know that this issue was something that they had previously encountered on a project and had a very negative outcome that directly impacted their employment.  As soon as I understood this barrier, we worked together to articulate the risk associated with the issue and clearly document mitigation activities.

Barriers Caused By Differing Levels of Understanding and Comprehension
Not all project team members have the same education level and comprehension speed.  It is important to take the time to understand what each individual brings to the project and how best to utilize those skills for successful delivery.  On one project I worked, one of the development team leads was especially good at working through logical timeline facilitation activities.  Typically these sessions would have been facilitated by the project manager.  On this team the project manager was new to the role and was not comfortable standing in front of the team facilitating this activity.  I instead approached the project manager about giving the team lead the opportunity to demonstrate leadership skills by giving him the opportunity to run the session.  I immediately saw relief on the face of the project manager and he was actually excited to approach the team lead with the request.  The team lead agreed and felt like he had been recognized as someone that could do something more than just lead developers in writing code.

Summary
The key takeaway from this article is the importance of taking the time to identify barriers you may face on your project and determine the best strategies to communicate effectively.

A special thank you to Jerry Johns for acting as my editor on this article!