nce upon a time, there was a kingdom of people who were busy managing projects named Pee-Em-Eye Ess-Eff-BeeA Sea. They were busy doing this work, and they found themselves wondering if there was a better way than just telling people what to do, and then scurrying off to the next project.
A small group of people in the kingdom thought that there was a better way to manage the kingdom of Pee-Em-Eye Ess-Eff-BeeA Sea. They believed they could apply some of their project management skills to help all the people in the kingdom to be more successful and happy.
One of the key success factors for any project is the “vision statement“, which is the Executive Sponsor‘s opportunity to excite the team, stakeholders, and customers with their vision of where we are going and how the product of the project will improve things.
When well done, the charter can be condensed into an elevator pitch for the project, and provide a clear vision to guide the project team to a common goal.
Vision: the capacity to see into the future. It’s setting a vision that people can see where their place in that vision is, and then coming across as deeply empathetic, human and intimate. The vision has to be a generous vision, such that people not only see their path in it but is excited about it. It is not just a plan, it is an enlistment. Great leaders have to be genuine and intimate: You have to feel like they touch you, and there is empathy or humanity there.
– Keith Ferrazi
The project charter‘s vision statement can galvanize the people to achieve defined objectives, even if they are stretch objectives, provided the vision is SMART (Specific, Measurable, Action-oriented, Realistic and Timely).
Simplifying – The most important thing to strive for is a simplifying effect on the project. A good vision will provide answers to the core questions individuals have, and will give them a tool for making decisions in their own work.
Intentional (Goal driven) – This is the first source of a project’s goals. It sets the tone for what good goals look like, how many goals there should be in the plan, and how much refinement the goals may need before they are complete. A well written goal defines a clear intention for the people on the team. One popular business acronym is SMART, which stands for Specific, Measurable, Action-oriented, Realistic and Timely. The idea is that if a goal has all five of these attributes it is likely to be well defined enough to be useful.
Consolidated – For the vision document to have power, it must consolidate ideas from many other places. It should absorb key thinking from research, analysis, strategic planning, or other efforts, and be the best representation of these ideas.
Inspirational – To connect with people, there must be a clear problem in the world that needs to be solved, which the team has some interest or capacity to solve. By giving the reader a clear understanding of the opportunities that exists, and providing a solid plan for exploiting it, people who have any capacity to be inspired, will be.
Memorable – Being memorable implies two things: first, that the ideas make sense or were interesting in some way; and second that they resonate with the reader and will stay with them. If the vision is too complex for anyone to understand it’s impossible to achieve this. Being memorable is best served by being direct and honest. If you can strike at the core of decisions and communicate them well – even if people don’t completely agree with those decisions – they will stay with people longer than those from a vision full of ideas they fully believe in but were buried in weak and muddy writing.
So what we want is communicate as clearly and concisely as possible in a way that helps people understand what we are doing. We want to help people visualize what they are trying to accomplish, and to give them a tool to reference when making decisions as the project proceeds.
With a well written project vision, the entire team is energized behind the goal, without it, each individual has to conceive the goal on their own.
A while ago, I made the conscious decision to pursue program management as a way to round out my skills in heading my career into the domain of technical leadership. I’d spent most of my career as a developer with my referent power derived from keeping one step ahead on the technology curve.
In my early career, I had managers and mentors who saw something in me that I didn’t see in myself, which was the ability to lead. Several managers tried to push me into leadership roles, and at first I pushed back, preferring to keep my head down, and learn as much as I could about everything that I could.
Well, you do that long enough, and those opportunities stop happening, so I found myself at a new place in my career where I actually understood the value of managing others. I’d finally realized that even if I was better than the people I managed, multiple people could get more done than I could as an individual. Even if they worked half as quickly as me, as long as there were enough of them, more work would get done and more quickly.
So understanding this, and meeting a few individuals who’d managed to make that transition from technical geek to technical leader, I set my sites on that CTO sort of role.
So I had an goal, and I had an inkling of an idea of how to get there, but still no formal plan. What occurred to me last night was that like any other goal, without a plan to get there, the path wanders, and you may never get there.
That said, I was conscious enough to know I needed to round my skills, and I did set my sight on some intermediate targets. First was to get some management experience, which was what led me to PwC and managing web development there.
The truth is, that I wandered a bit more in my career, not really making direct progress toward anything like the CTO role. I gathered a bit more experience as a technical architect, expanded my skills leading small teams, and learned a lot about being a consultant and managing expectations. Still, without a plan time marched on.
Image via CrunchBase
I was exposed to solid project management at places like Cisco (which is probably the most project based organization I’ve ever worked at) and the value of true project management. It occurred to me that moving into the project management end of the process would round my skills in a way that being an architect would not. It would also round out my business and soft skills in ways that the more technical role would expose me to.
So having no idea what project management was, I talked to a few of my friends and heard about the Project Management Professional (PMP) certification from the Project Management Institute (PMI). From watching a few of the better PM’s that I knew go through this certification, I had no doubt that it was a challenging and as real a certification as any I’d come across.
I took a couple of PMP prep classes and studied as much as I could, in order to understand the best practices of project management. I began to understand things that I was doing right, and reasons for things I had not understood before (like what a critical path actually was).
Image via Wikipedia
During the “downturn”, I became more involved with expanding my skills through volunteering and continuous learning. I helped to form a non-profit aimed at getting people jobs, and learned a great deal about interpersonal networking (both virtual and physical).
Continuing that growth in leadership, I’ve joined the board of directors of the PMI San Francisco Bay Area Chapter as Secretary and VP of Operations (officially starting on April 1st, 2011).
Now I’m feeling the skills are getting pretty rounded, and I still don’t have a real plan to get from here to there. So the first step in my plan is to write down that I need a plan. Next I think I’ll need a few good mentors to help me figure out a real plan ….
I was talking to some friends last night about how we have a nice team of consultants that could do some really interesting projects, when I was reminded of some lessons I learned working for a small consulting firm.
During the dot-Com explosion, a small consulting firm couldn’t hire people fast enough, and it was easy to cherry-pick the jobs that made sense. When I first joined the firm, the focus of the team I was on was to take on full projects for companies that were having similar problems (nobody could find people, so they were willing to have outside teams of experts help them invent their core business). During this period, our biggest problem was not having enough people to take all the cool projects that were coming our way, so we never even considered placing less than a full team on a project at a client site.
As the dot-Com explosion became the dot-Bomb implosion, we were (like most consulting firms) faced with a different problem. There was nothing in the pipeline. Worse, the company had spent a bunch of money on things they thought they needed to do to go public (like building an ASP hosting service) and taken money from investors, which left the management with difficult choices to make.
There were lay-offs (mostly sales staff), and cut-backs. And naturally, the business model changed, since to keep the doors open it was important to keep everybody billable. So we placed people wherever we could, which meant a lot of “body-shop” type of gigs, where we were supplementing people to projects. This, combined with the layoffs, meant our bench was thin, which in turn meant we could no longer handle full projects. Eventually this resulted in the company turning to a policy of “if you’re not billing, you’re not getting paid”, which resulted in a lot of the more effective consultants (like me) leaving the company.
The most interesting thing about this to me is the fact that there is some critical mass of consultants that you need to have in order to do project based consulting (where you “own” the project). You need enough people so that you have teams working all of the time, and to be able to support the teams between engagements. If you aren’t large enough (or the economy is bad enough), you can end up trying to keep the firm going by placing individuals, but that will almost certainly reduce the number of projects that you can do (since now that critical person is no longer available for the team).
In fact what we saw was that the “body shop” approach, kept the most critical people extremely busy at the expense of those who were not in such high demand. Project managers, architects and DBA‘s were placed, and so when a project came along, were not available for a team based project. And of course the vicious cycle would be that since we couldn’t take these projects, the people who weren’t being placed would leave, which inevitably led to other people leaving …
Eventually the economy recovered (as did the consulting firm), but I’m thankful for this magnifying lense on how difficult it really is for a small consulting firm to be successful. It almost always comes back to focus, except of course when it comes down to survival.
I recently had an experience that reminded me that you truly can negotiate anything.
I got a call from a buddy telling me that he his manager was looking for a contractor to replace somebody who wasn’t performing to the level they needed in a business analyst type of position. The person they were replacing was a low-range contractor, so the rate they had been paying was substantially lower than what I’ve been making (as a program manager), but they also expected they’d need to pay more to get the skill-set they were looking for.
That set my expectation to expect that there would be some serious negotiation around rate, so I tried to take my usual approach: avoid discussing rate with the client. In general I was able to succeed, and and instead talk about the job and how I would be effective in helping them (particularly in areas that the prior person had failed).
I do have another rule, however, which is that I will honestly answer a question put to me directly, so inevitably the question of rate did come up. The dreaded question of “what was your last rate?” comes up, and is always uncomfortable for me. I thought I did a good job of answering the question by letting them know that rate is not the deciding factor for me, that I expect a fair rate for the work being done, and that I wasn’t expecting anything like my prior rate. After that preface, I did let them know my last rate (as a program manager on an implementation project), and tried once again to set the expectation that I wasn’t expecting to recieve that sort of rate on this engagement.
I had this conversation with the Director of the group that was looking for help, and everything went well there. We connected well on our phone screen, and he turned me over to his hiring manager to complete the process (since it was her group and I’d be working for her).
At the end of the process I asked my usual questions about how I did, and whether they had any concerns that would keep them from offering me the job. It seemed I had done well, and that the next step was for them to complete their interview schedule, and check references. The Q&A about prior rates came up again, and I thought I once again responded with rate not being the deciding factor for me.
I diligently followed up with a thank-you email to each member of the team, and continued to ask my buddy about my chances. Eventually I got an email from the hiring manager telling me that it was between me and one other candidate. My friend told me there was no comparison, and that the only reason I might lose out would be on rate, since I was more qualified and had his backing.
After another weekend, I got an email from the hiring manager telling me that they had decided to go with the other candidate based on rate. This surprised me a little since I didn’t really think we’d ever discussed rate. So I dropped an email back to the Director (cc’ing the manager) asking why they thought my rate was too high when we hadn’t discussed it. I carefully crafted the email as a question about my communication skills and helping me to improve them:
I heard from <your manager> and my friend that the decision was to go with another candidate based on rate.
I was a little surprised since I didn’t think we had gotten to the point where a negotiation of rate had started, beyond my responding to questions about my rate on prior engagements. My experience in the past has been that if the rate is too high, they simply ask me if I’ll take less.
If you could help me out in understanding if I set an unreasonable expectation, or if this was instead just a matter of the other guy being a better fit, I’d appreciate any feedback you could give me.
Interestingly what the net result of this email was, was that the negotiations were reopened. He replied to me that they had compared the rate I had told them from my previous work, to the rate that the other contractor was asking for, and simply assumed that I wouldn’t be happy with a reduced rate. We traded emails back and forth a few times, and we agreed on a rate that was the same as what they were looking for with the other candidate, and it felt like there was a chance I’d won the engagement.
In hind sight, I think one mistake I made here was sending this email to the Director instead of to the hiring manager, since she was the one who would ultimately make the decision. That said, I did re-learn a valuable lesson about negotiating: it ain’t over until it’s over ….
It’s all about getting to yes, and by asking these people if they could help me understand why we hadn’t negotiated on rate, I helped them understand they could have negotiated for a more valuable resource a little better, and kept the negotiation open.