What if you are your project’s biggest risk?

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

“A little knowledge is a dangerous thing” – Alexander Pope

While I was studying to become a project manager, I believed what A Guide to the Project Management Body of Knowledge (known as the PMBOK) and my professors had to say as the gospel truth: a project is a project is a project. It didn’t matter that I had no experience building a bridge, planning a wedding, or configuring a database server…I was going to be a professional project manager, and that meant that I could manage anything (so long as I followed the 5 phases of the PMBOK and did everything that the 11 knowledge areas told me to do)!

For a while, that was the case. I made sure that all of my projects had strong technical people that were good communicators so as to provide good estimates, identify risks early and often, and manage the details of the deliverables. I was able to focus on managing at the executive level, facilitating problem resolution, and provide project administration support.

But then it happened – I was assigned a project where I had a little bit of technical knowledge, but not much, and was paired with some intermediate resources. They were technically strong, but were relatively inexperienced in working in a large project setting. At the time, though, I did not know this and just assumed that they were as skilled as every other project team I had worked with in the past. When we sat down to plan, I used the same process as with my other project teams; when we ran status meetings, I used the same process as with other project teams; and when we identified risks, I used the same process as with other project teams. However, development activities continued to miss dates, and my inquiry into what went wrong with the team yielded answers like “we don’t know.”

As a result, I used my fairly limited knowledge of the subject area to help plug the gaps that I saw. When asked questions by the sponsor and subject matter experts, I gave them answers that I believed to be true without consulting the team. When asked questions about the technology by the IT operations team, I gave answers that I had heard given in the past without consulting the team. And then things started to go really wrong. The client kept asking the team about things that I had said, and were told opposite things, the project team kept freezing me out of discussions, and my Program Manager came back to me with feedback that I was about to be fired from my project.

At that point, having a team that was not as strong as my previous teams was not the issue. My assumptions, silo’d decision making due to frustrations, and unfair expectations of the team introduced a myriad of risks, which of course I didn’t capture in the risk register, to the deliverables. These risks almost immediately became issues when I communicated out without consulting the team. I was the issue. I was the project’s biggest risk to scope, schedule, and budget.

So what should I have done?

1. Don’t assume you know everything

Even though I had some experience with the technical area, and was a well seasoned project manager, I should not have assumed that I knew better than the team. It’s ok to say “I don’t know”, so long as you promise to get the answers and follow up.

2. Consider your team’s requirements

Instead of forcing the team through processes that worked well for other teams, I should have considered their requirements in the locus of their experience level. During the “forming” and “storming” phases of team development, I should have been asking questions rather than imposing processes. When I saw a process that did not work, I should not have knee-jerked into command and control mode; rather I should have worked with the team to re-assess.

3. Recognize that you cannot push a rope up a hill

As a project manager, it is your job to facilitate successful project outcomes. Unless you are explicitly performing a specific role on a project team, your only true deliverables are status reports, communications, and facilitated sessions. It is up to your team to deliver the technical content. If there are performance issues, talk to the team members (and then their managers if required). If there are scope concerns, talk to your sponsor. If there are resourcing concerns, talk to your project management office. Do not try to own the issue; try to facilitate resolution.

In the end, I focused heavily on #2 and #3 and struggled with #1 through to project closure. After giving answers for so long, it was hard not to. As far as the project was concerned, after a re-baseline, it was delivered to scope, schedule, and budget constraints.

What type of learning opportunities have you had through projects? How else could a Project Manager be the project’s biggest risk?

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!

You've Collected Data...But Now What?

Post written by Peter T., Management Consultant at Ideaca. Read more about visibility on his blog: Visibility.

The list of technologies that allow us to capture vast amounts of data is quite extensive. This list varies in magnitude of use and exposure within organizations. Companies today can, and most often do, use multiple means of collecting data, such as: Spreadsheets, Databases, Operational specific Software, Enterprise Systems; ERP, CRM, HRM, Various Portals; Personal Portals, News Portals, Enterprise Information Portals, Self-Service Portals, e-Commerce Portals, Collaboration Portals… And the list goes on and on.

It is very evident that companies are really good at collecting data. Whether the data management function within an organization is primitive or advanced, gathering data in spreadsheets or in elaborate enterprise systems and databases: the majority of organizations are great at data collection. Hard copy, Soft Copy, e-Copy, web displayed; data in all forms, shapes and sizes is being collected at an enormous pace. If you can write it, print it, draw it, type it, sketch it, draft it, and capture it, you can rest assured it is being gathered.

The question is not what data to capture next, but now that we have all this data, NOW WHAT?  

Once data is collected, do organizations use it in the most efficient way? The overarching question is: now that you have all this data, what value are you getting from it? The following are five steps that will assist organizations in gaining the most value out of their data.

STEP 1 – IDENTIFY YOUR VALUE DRIVERS

Before we can successfully answer the question of value derived from data, we need to understand what the value drivers are for an organization. Are the value drivers; profitability, reputation, market share, productivity, customer service? The list can certainly be expanded upon. Getting value out of your operational data is imperative, but if you don’t link the data that you are capturing with the value drivers of the organization, you could be spinning your wheels and not realizing the full potential of your systems and efforts.

STEP 2 – LINK DATA TO YOUR VALUE DRIVERS

The next step to ensuring you are making intelligent decisions based on relevant information is to verify that all data captured is linked to the value drivers of your organization. Every piece of information that is collected and processed is intended to provide new intelligence, thereby improving the positive outcomes of critical operational decisions. The way to optimally perform this is by linking significant data retrieval and performance functions to your value drivers. Furthermore, these links can be expanded upon where multiple associations exist.

Dissecting the specific data captured will allow organizations to assess data accuracy, timeliness, depth, and most importantly the interconnection with various other data sets and systems. The key is to ensure that crucial data is modeled to display how it is gathered, at what interval, and how data from one source is related to data in another.

STEP 3 – ANALYZE

Now that you have modeled all significant operational data, you will be able to focus on the highest impacting pieces. By designing new processes or re-engineering solutions, you will be able to increase the usefulness of the information. The analysis will be focused on interconnecting data, assets, management, and operational systems. This exercise will require a thorough look at the data to ensure that standards are in place and the collection of information is from across the entire organization in order to ensure corporate-wide accurate reporting. The outcome from the analysis is to design a roadmap that will focus on operational improvements tied directly to the value drivers of the organization. This can be initiatives such as: identifying ways to increase production, improve safety records, decrease maintenance costs, improve asset visibility, reduce compliance risk, and much more.

STEP 4 – SOLUTIONING

After defining opportunities to improve operations, organizations need to devote some time to developing a realistic plan of achieving these goals. A key step in the Solutioning process is developing the overall vision and detailing the various components of development in palatable sizes ready for execution. Increasing the capabilities of the organization through the design of new automated systems or enhanced analytics, processes and interfaces are just some of the improvements that can be realized. If structured properly, these enhancements can provide the organization significant wins by capitalizing on the information captured along the way.

Information Technology has assisted organizations in navigating from simple and non-existent data management environments, to an optimized level where data can be used for benchmarking and analysis to drive their strategic and operational initiatives. This cannot be successfully done however without ensuring that all data captured provides value and that value is something that drives the automation, analysis and design of advanced systems and integration opportunities. The following diagram depicts the stages of data management and provides a visual of where organizations currently are and how far they may have to go in order to achieve the most optimal level of data management:

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.

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!

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! 

Beginning with the End in Mind: The Solution Design Document

Imagine for a moment that you are building a house. You know you want 3 bedrooms, a functional kitchen, and extensive entertainment technology incorporated into every room. Go! Those are nice ideas, but they really don’t narrow it down much, and they certainly aren’t enough to communicate to the myriad of contractors, sub-contractors and trades. What would this house look like? Could your general contractor estimate on these requirements?

You wouldn’t expect such enigmatic ideas to be good enough for a construction project, so why would we expect IT projects to be any different? Most IT projects begin with similar vague ideas. Statements like “central information repository”, “seamless integration with the enterprise systems”, “easy to use graphical user interfaces”, and “improved business processes” are common high-level requirements. These types of statements are traditionally present in project charters and speak to the business goals. But just like that house you want to build, these are not enough to provide the required clarity to all of the stakeholders.

Enter the Solution Design Document

Sandwiched between the project charter and detail technical design documentation, the solution design document fulfills a critically important role in any IT project. Why do we need pretty pictures? What’s all this non-technical stuff good for? What does WebDAV mean? These are the types of questions I’ve received over the years and here is my response;

• It provides the big picture to a broad audience.
• It communicates what the outcome will look like and how it will be achieved.
• It provides sufficient detail to allow project sponsors to make informed decisions.
• It uses language that is not exclusionary or overly technical while at the same time contains detail to be of value to technical resources.

Creativity in Leadership

 

Creativity is the individual way in which our mind generates our views, ideas, style…or any other facet of the imagination. Through this comes expression which is the product of creativity and exists in many forms… one of which is leadership.

Being a leader is an immeasurable opportunity for growth.  You are being given the chance to influence and be influenced, learn as well as teach, and guide in your own unique way.  Of course there are some basic guidelines, but each individual will bring their own flare to leading a team to a successful finale.  What you choose to do and say will inevitably create an experience for everyone on the team, including yourself, and give you the capacity to profoundly shape a project and the people who are a part of it.  Your creative abilities may come as new strategies to tackling a tight schedule, your technical understanding, or sheer ability to make people feel important.  Wherever your inherent virtues lie, being put into a lead role will assure they have the chance to develop and shine.

It’s important to have a foundation to build upon, so consider these points the canvas for your creative endeavor:

Be confident  -  You must believe if you want others to believe in you. Carry yourself in a manner that exhibits strength, encourages excitement, and gives a sense of stability.  The way you step forward as a leader permeates the air around you, and has a profound effect on how people see you.  Their belief in your ability to guide instills confidence in them as well, and inspires great performance.  In the midst of this exchange of recognition is the creation of trust, which in the aspect of a project will go a long way.

Know your team - Just as you have your own way of being in the world, so do your team members and recognizing the exceptional qualities that each team member brings to the table will tremendously further your ability to attain success.  Pinpointing a person’s strengths in the beginning will allow you a broader insight down the road into delegating appropriately to utilize the team’s greatest powers when and where they are needed.  In doing this you are aligning with efficiency by pushing forward peoples talents. It gives people a sense of purpose when they know they are essential and why, it drives ambition and productivity and a sense of self. This is a great form of expression.

Know where you are headed – Visualize the end result, or final product.  Know in your mind that you will achieve the best final result possible and exceed expectations and how it will look when you’re there. If you can imagine it, you can make it and this is a force to be reckoned with.  Every project is susceptible to encountering obstacles along the way, but having a vision will help you navigate around roadblocks thus maintaining a clear path to success.

Keep in touch – Communication is vastly key to so much in life and especially in a collaborative situation.  The ebb and flow of a project is directly associated with straight up talking to and amongst one another.  The individual components that each team member is responsible for will amalgamate to form the final, tangible result and in order for that to happen there needs to be a streamline of conversation.  It is vital to not only deliver project updates to the team but to exchange thoughts and ideas. In doing so you are creating an environment of constant awareness of the state of the project as well as combining the team’s brainpower to solution any challenges that may arise. Not to mention it unifies the group socially, which can create an immensely dynamic team when they are called to duty.

When you consider these concepts and ignite them with a passion to do great work and do it with your own style, you can come through the other side having not only delivered an intended product, but having done it with the rare qualities only you possess.  Your character and personality make you a leader unlike any other seen before, or that will be seen.  It is the chance for you to leave a mark that will impact others in a positive way, and hopefully make a difference in some way…somehow.  Because once the project is over what people have left (besides a fantastic new…….[insert your project delivery here]) is the memory of how it came together and the people who made it happen.

- Joelle Thrasher, Portals & Collaboration Consultant

Follow @Ideaca

Beyond Project Management to Project Leadership

Check out this recent post on Project Management from Ideaca Partner, Evan Hu's blog "at the intersection of innovation, entrepreneurship and leadership". Evan goes into detail about why projects fail, and what you can do to ensure future success.


Beyond Project Management to Project Leadership

Follow @Ideaca