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?

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:

• In the legal sector, project management has been a fairly hot topic since approximately 2010. It’s also getting more attention in law schools.
• Digital Ad Agencies position project managers to help their customers realize a marketing vision.
• The Human Resources designation – Certified Human Resources Professional (CHRP) - now has a focus on Project Management.
• Investment Banks have started hiring project managers to help manage deals.

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?

Project Management and Big Data – as a project

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 Big Data.

This is going to be a 2 part post:

• The first part will cover how you, as a project manager, should approach a project that carries the mantle of “Big Data.”
• The second part will cover how you, as someone in a Project/Program Management Office, can use Big Data without getting snookered by the hype.

Part 1 – So you’ve been asked to “implement Big Data”… what now?

Defining Your Terms
I am going to assume that you – like me – tend to be baffled by the marketing speak until you can speak with someone intelligently about a topic. In the case of Big Data, I have heard a few definitions. The one that seems to stick the most for me is the one from Wikipedia:

• Data sets that are too big for traditional database management systems to handle
• Data sets that comprise information from multiple sources to try to infer correlation

Sounds easy enough, right?
Where it starts to get complicated (thanks Wade!) is when you try to integrate “unstructured and semi-structured data with our 'traditional' structured data.”

You will never “implement Big Data”
When it comes to Big Data, you do not implement it. You may be implementing a technology to support the analysis, but you will never actually implement this “thing.” A project of this sort relies on understanding the user requirements, selecting the right technology, and taking an exploratory approach when developing reporting capabilities.

Understanding the User Requirements
In the case of a new process and technology, such as this, your user requirements may be fairly light. "We want to correlate information from disparate sources to identify predictive trends” or “I don’t know – but I really want some cool looking reports” may be common lines that you hear. Like all projects, the user requirements are your definition of success. Because “Big Data” is still a technology in the exploratory stage, though, expecting detailed requirements may be the wrong sorts of requirements. The ones that you should be really focused on are the data sources and ensuring that the information being presented is right.

To wit, if I were to ask you to present the information on the average CEO compensation for the top 50 companies in North America, how would you start? How would you define the Top 50?  By Market Capitalization? By Environmental Performance? By Stock Price? By Revenue? What about getting access to private company information? All of the sudden, a fairly simple question about the average CEO compensation gets a little more complex.

The same will be true of your Big Data project. Start by understanding that to present the information your users want, you will either have to ask a whole lot of detailed questions, or provide a platform to enable them to answer their own questions.

Understanding the available technology
As Project Managers, we know that when we are asked to Implement something, it’s never that simple. Understanding what the technology can and cannot do is critical to ensuring that your project can meet the user’s definition of success.

One might want to satisfy the guiding principles of a company’s Enterprise Architecture. A quick scan of the landscape will reveal that tools like SAP HANA, Oracle’s Exadata, and Amazon’s AWS can all fulfill the technology requirements quite nicely and potentially support a company’s Enterprise Architecture. However, since this is a new application of technology, fulfillment of requirements needs to trump Enterprise Architecture.

Take an Exploratory and Iterative Approach to reporting
Some organizations will judge success of your project by its ability to deliver a load of reports. If this sounds like your organization, be realistic as to what can be delivered. Deliver a robust and reliable dataset, some transactional reports, and one report that really helps demonstrate the art of the possible.

Smarter organizations will judge the success of your project by its ability to deliver analytic capabilities to the user base. The robust and reliable dataset is still mandatory, but the ability for users to generate their own reports will satisfy all of the “what about …?” requirements that would blow your project budget and schedule out of the water.

In the end… it’s the people that matter
If we believe all of the marketing hype, Big Data will help us explore all the myriad of ways our world is constructed. But from the perspective of a Big Data as a project, an empowered user base will produce much more value than some canned reports.

Have you been asked to “implement big data”?
If so, what did your project look like? Let me know in the comments down below. Stay tuned for another post on making the most of Big Data in a PMO.


Special thanks to Wade Walker and Chris Sorensen for keeping me honest with this post.

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!