-->
Showing posts with label projects. Show all posts
Showing posts with label projects. Show all posts

Tuesday, 11 February 2014

Advice For Junior PMs – Do Not Be Afraid To Communicate Risks That Have Become Issues

Post written by Jason Z., Project Manager at Ideaca. Read more about project management on his blog: Unnatural Leadership.

You saw it coming. You captured it in the risk register, reviewed the mitigation plan with your team and had them alter some of the response strategy. It’s even part of your status report. And then the risk event occurred, but you didn’t know how to have the conversation with your project sponsor.

I understand. I’ve had some awkward conversations myself. It can be intimidating to walk into your sponsor’s office for a status update and having to try to (not so subtly) clearly say that you will need more money, time, or resources to properly respond to the risk event and keep the project on track.

So how should you handle it? What should you have done?

Before the project begins, provide your sponsor some context of the situation. Not all status meetings will be positive progress updates, but not all status meetings will require intervention. You are there to be honest and to steward the process, not sugar coat things. Besides, when it comes time for the risk event to occur, you have identified it and have a response plan.
If you are stuck, and feel like you need to save your skin during the project – don’t panic. If your sponsor has even one more grey hair then you, this is not the first time they have had to have this type of conversation. Be honest, be confident, and have your facts in order. You have identified the risk, and you have a response plan.

For both circumstances – ensure that at subsequent status meetings, you are reviewing risks that are relevant for your current project phase.


Have you ever had a really awkward conversation about risks with your sponsor? How did you handle it?

Monday, 6 January 2014

Project Management isn’t just for IT or Engineering anymore

Post written by Jason Z., Project Manager at Ideaca. Read more about project management on his blog: Unnatural Leadership.
As part of this month’s Ideaca blogging network challenge, we were tasked with discussing our thoughts on Emerging Practices.
One of my favorite quotes to reference from the The Project Management Body of Knowledge (PMBOK, pronounced pemmmmbock) is “As project management is a critical strategic discipline, the project manager becomes the link between the strategy and the team. Projects are essential to the growth and survival of organizations.” So, while operational duties are of very high importance to maintaining the forward momentum and revenue generation for a company, projects are strategic and help organizations react to changes in the external environment that may slow forward momentum and/or impair revenue generation.
Taking this as rote, one Emerging Practice that I am pleased to see is that more industries and functions – outside of Engineering and IT – are recognizing the need for project management:
So what does this mean for Project Management as a career? It means that effective Project Management is not just for IT and Engineering anymore. In fact, the rest of the organization is going to have to contend with:
  • Increased workloads for Subject Matter Experts. If you know the organizational area, you must know how to manage the project to do something in this organizational area.
  • Gone are the days of black box projects – clients are demanding more visibility into what is being delivered, how it’s being delivered, and how delivery is progressing.
  • Organizations are demanding value from their staff’s time - projects are going to have to deliver more than a “thing.”
  • Successfully implementing changes in an organization can no longer be ad-hoc, and to a lesser extent grassroots. Rather, efforts must be controlled activities.
This is both amazing, and troubling at the same time. It’s amazing because having proper control, visibility, and communication for organizations can return recognizable and material value. It’s troubling though, as many organizations may start expecting their people to be expert project managers without any proper training or experience (this link is a great discussion on LinkedIn, by the way).
If your organization is transitioning to more of a project focus, and you don’t have the time or desire to become a fully trained PMP, there are a number of ways to get up to speed on how to be effective:
  • Hire a dedicated (or shared) Project Manager – This person should be able to apply project management best practices while you are focused on the subject matter at hand. If your department doesn't have the budget or enough work for a full time Project Manager, share the PM (both cost and time) with a different department.
  • Mentoring – Junior PMs will often work with Senior PMs for mentoring, so why not do the same? Your company should have a PM for you to reach out to, or you can contact someone in your local PMI chapter.
  • Training – Most colleges offer introductory PM training. In exchange for some of your time over a couple of weeks, you can get trained up on how to run a small project effectively.
  • Reading – There are many great books available. One that I recommend is Project Management Lite: Just Enough to get the Job Done…Nothing more. Another, more detailed, is the big bible - Rita Mulcahy’s guide to passing the PMP on your first try. You don’t have to attempt the PMP, you just need to read this book.
Has your organization made the transition to more project-based initiatives?  How has it impacted you?  What have you learned?

Thursday, 10 October 2013

The importance of a shared vision

Post written by Jason Z., Project Manager at Ideaca. Read more about project management on his blog: Unnatural Leadership.

In a post from my series “Advice for Junior PMs," I touched on the concept of saying what you mean when working with your project team. The same concept should be applied when communicating outside of your project team.

There’s a fairly common graphic that gets passed around IT departments, and it’s somewhat self-deprecating. It shows that project teams tend to not understand what the customer needs – which is endemic of lacking a shared vision.

This graphic makes me cringe every time I see it.

As we all know, a project is a temporary group activity designed to produce a unique product, service or result. However, more often than not, project teams take an “I know best” view of the world when designing solutions for their customer.

A strong project manager will not only sit with their customer to understand what is required, but will bring the whole project team along to understand as well. We all have our own perceptions and filters, and as a result may play broken telephone.

At this point, you may be asking if a shared vision is different from the project scope statement. It is, in that the shared vision is what the customer will see as the product, service, or result of the project, whereas the project scope is everything that will be delivered (including training, documentation, organizational change management).

To create a shared vision of what the project will produce (be it a unique product, service, or result):
  1. Bring everyone to the table to ensure open communication
  1. Define what is to be produced in simple language – do not say “we are going to produce a tree swing,” and leave it there, say “we are going to produce a tree swing, which is comprised of a tire hanging from a sturdy branch of a large oak tree by a piece of polyester rope.”
  1. Involve the customer in design meetings. Subject Matter Experts (SMEs) should definitely lead, but should be eliciting feedback so that the customer’s requirements are re-confirmed by the team.
  1. Revisit the shared vision often. Ask your customer at difference acceptance testing points if what is being developed meets the shared vision.
Most importantly, communicate the shared vision often. Use it as the first line in your status reports, use it as part of your elevator speech, and when people ask you what you are working on, relay your project’s shared vision.

What are your tips for creating a shared vision? What have you seen work well? Do you have any stories of spectacular failures? Share your tips and stories below!

Thursday, 19 September 2013

A hike gone awry as an analogy for Troubled Project Leadership

Post written by Jason Z., Project Manager at Ideaca. Read more about project management on his blog: Unnatural Leadership.

I have two fortune cookie fortunes on my desk at home – “promise only what you can deliver” and “now is a good time to finish up old tasks.” They are taped to the bottom of a picture frame with a picture of my wife and I from the day that she had a catastrophic accident hiking in the mountains. 

We were hiking “Bow Peak” with a friend in the middle of the summer and  decided to summit the peak. When we reached the peak, we realized that there were three paths down, but we had no guidance as to which path to take. Our goal was to get to the base of the summit, which connected to the safe path down. The first path was the one we came up, and it was all scree.  We didn’t really have the right gear to descend safely. The second path was down a rock chute to a wide open path, and we would have to walk an extra 15 km to get to the base of the summit. The third path was also down the rock chute, but it turned to a side of the mountain that we could not see.  However, we could see that it was a shorter route and would take us over some less dangerous scree to get us back to the base of the summit.

As a group, we identified the problem, recognized the constraints, discussed the risks of each path, and then chose the third path for our descent. Before we began, we agreed on some of our guiding principles for descending – such as only one person in the chute at a time so as to avoid being hit by tumbling rocks.

During our descent, we came across a part of the path that was previously unknown – we had to traverse and descend a small glacial formation. I went first, and having experience snowboarding, sat down on my heels and enjoyed the 60 foot slide. My wife (then girlfriend) went next, but did not have the same experience. She slid out of control and ended up breaking two teeth and puncturing her lip on a flat top rock. As she was sliding, I was trying to give her all of my knowledge of how to control the uncontrolled descent by yelling four words – “dig in your heels.” She yelled back “I am! I am!”  I didn’t offer her how to do so, or what else to do with her body when she was doing so. And so, as she was sliding, I was sprinting across the base of the ice to catch her before she hurt herself. I was too late, and we ended up spending the night in hospital followed by the next morning with a dentist to perform some emergency repairs.  The final result was that she endured 20 stitches in her lower lip and now has 2 false teeth.  While she will still come hiking, she is not as exuberant to go as she once was.



Our friend – who happened to have a med kit – ended up taking the 'safe' route down by walking down the side of the glacier where it was primarily slush.

I have never forgiven myself for that accident, but have never thought about the leadership lesson associated with it. In the short time span of her fall, I could not even begin to communicate the depth of my experience to ensure that she would be successful with her journey. I had just assumed that it would be fine if I showed her how to do it. When I saw she wasn’t getting it, I started yelling louder hoping she would get it.

By reflecting on this hiking experience, I now understand some of the more tumultuous projects that I have managed and participated on:
  1. As we prepared for our descent, we discussed our guiding principles for descending. Creating a shared vision through detailed planning is the logical way to get a team ready to move forward with a project. However, I have observed, and participated on, project teams that just move forward without considering what could go wrong.
  2. Project teams have disparate skill sets. While some members may be perfectly happy to “descend the glacier,” others may not be. Ensure that teams have a safe path to move forward without getting hurt.
  3. When the pressure is high and time is short, yelling does not help anything.
My lesson to be applied is thus:
  1. Be deliberate with your plans
  2. Consider skill sets
  3. Having someone with experience walking the path can provide helpful guidance, but they do not necessarily add value when they are “in charge.”
Long hikes are a lot like projects. To descend the mountain safely, you need to honestly assess team skills, previous experience, and know how to prevent catastrophic accidents. Never walk the path blindly.

Tuesday, 17 September 2013

Setting expectations with clients (part 2)

Post written by Steve J, Project Manager at Ideaca

Setting Expectations with Clients Part 2 is a two part blog series on managing client expectations. See here to read part 1.

In my previous blog post, I told a story about a project I was involved in that required expectations to be managed and the project to be pivoted. In this blog post, I will discuss four key factors in managing expectations that I have learned throughout my career.

1. Communication is a key factor when working with clients. No two clients are the same, some will hire a team to complete a specific task, while others will want to be fully engaged. Learning how and when to communicate with these different groups is crucial to project success. Fully engaged clients may require daily or even hourly updates on project status while more removed clients may only want occasional updates. Knowing your client and making decisions on when and how to communicate is an important way to manage expectations. Some of the effective communication mechanisms that we use on projects can include: daily stand-up meetings with the entire project team (including the client), weekly status reports with all items completed that week, any issues or decisions that arouse, and a budget burn down showing progress. Email is a very handy tool for communication, however if a portal (SharePoint or something similar) is available, this technology will allow for much tighter control over issues, questions, and decisions on the project, without the issues with email branching off into numerous threads and side conversations.

2. Building a relationship on honesty is necessary. Right from the first meeting, the client should understand what you can and cannot do for them. As much as we wish we could offer solutions to every problem, the reality is we can only do what is within scope and within our knowledge and skills. While digging into the details of what that desired end state will be, it is important to discuss what is possible and what is not. These discussions will affect the project and the decisions made will impact the deliverables, the timelines and especially the budget. The hope of this is to catch and identify any areas of the project that may lead to deliverables not being delivered, budgets and time frames expanding and missing expectations.

3. Deciding the roles and responsibilities for the project team (including the client team members as well) is a major task that should be completed at the start of the project. From the start of the project, setting up a project Governance is a great way to start. Project Governance will outline the relationships between all groups involved in the project, define the flow of information from the project to all key stakeholders, and ensure that there is appropriate reviews of all issues during the project. Another useful tool is to create a RACI Matrix. A RACI matrix describes the participation by various roles in completing tasks or deliverables for a project or business process. It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes. Key contacts for the different areas of the project should be also defined. It’s important for everyone to know who to go to for questions and issues with certain aspects of the project and to keep these people consistent from kick off to go live. In projects I have been on, we start the project with an internal kick off meeting before we meet with the client. This ensures everyone is on the same page and has a shared understanding of the project and statement of work. On the first day of work with the client, we begin with a similar meeting. At this point we can assign the key contacts on my project team as well as the clients’ team. Everyone involved on both sides will have had chance to meet and put a name to the face and to their role.

 4. “When is the due date and when can we launch this project?” should be questions that are asked and answered early on. Making sure to develop a realistic project plan adds transparency to the project, shows when the milestones are due and provides everyone responsibilities and accountabilities. The project plan is a living document. It should exist to provide everyone an up to date snapshot of where things are in the project. If there are delays or changes made, the project plan should be updated and discussed with the client immediately. When it comes to managing expectations, establishing clear and consistent deadlines are a necessity. The sooner deadlines are set, the sooner the team can begin to work to ensure they meet them.

Every new project allows for lessons learned or growth, both for the team and the individual. Personally, I have learned so much about managing expectations from every project I have ever worked on. Every client is different and understanding how to work with them is part of having a successful project. Communications, honesty, assigning tasks and confirming deadlines are four key aspects of managing expectations that are part of my expectation management strategy for every project. Ultimately you want to start the project the same way that you finish it: with happy clients!

Tuesday, 10 September 2013

Setting expectations with clients

Post written by Steve J, Project Manager at Ideaca

The Oxford Dictionary defines “managing expectations” as: “Seek to prevent disappointment by establishing in advance what can realistically be achieved or delivered by a project, undertaking, course of action, etc.”

Almost every part of our lives is surrounded by expectations, either ones we set for ourselves or ones that were set for us by others. When it comes to consulting and being on a project, every part of the project experience will be influenced by expectations. There will be expectations around the project as a whole, the deliverables, the time and especially the budget. It is the responsibility of the project team and Project Manager to ensure that the client has a clear and accurate understanding at all times. The overall success of any project will be linked to the expectations of the client, the understanding and efforts of the project team and how well these factors align. At the end of a project, the client’s satisfaction with the delivered project will determine its success.

I have worked on a variety of projects, including those with high expectations from the client. In one project the client as a whole had very little technical and user knowledge of the system that we were implementing for them. They were very much involved in the project and took on many tasks. One of the tasks that was completed by the client was the design and layout of the new system. This task was completed before the project team started on the project and with limited knowledge of the system. The designer was able to design the pages to match that of a SharePoint look and feel without any operational knowledge of the system as a whole. The project team was not a part of this design and the client wanted the end result to look and operate the same as they had designed it. When our project team realized this, we had to pivot our work to align with a more customized solution rather than an out of the box implementation as originally expected. Communication and managing expectations became a critical component of this project, especially since the plans and timelines shifted substantially. Working closely with the client, being honest about timelines and budget and reviewing changes before work continued were very important. Our open communication kept the client informed and the project team on the right track to meeting their needs. In conclusion, the client was very happy with the end product and assured us that we had exceeded their expectations.

Through my experience working with a variety of clients in different situations, I have developed an understanding of how to best manage client expectations. As in the example above, the situation could have turned out with one, or both parties upset about the changes in plans. But by effective expectation management, we were able to explain to the client why things needed to change and what exactly we were going to change. This turned a potentially problematic shift in work into a positive improvement of work.

In my next blog entry, I’ll cover the four key factors in managing client expectations that I have learned throughout my career. Check back next Tuesday, September 17 for more!