Adjust your dreams to align with reality and what's possible (focus on next steps)

Take one step at a time and focus on the water.
Maybe it's good, maybe it's not.  To dive in or not?

Dwelling--or really spending much time at all--on analyzing the way things are or why they are the way they are is kind of a messed up, useless waste of time but apparently we have to do it as humans.  I'd rather spend my time imagining the future and figuring out what I need to do to get there.

Focusing on where we want to go and figuring out how to get there is a really important and necessary thing for us to be happy.  We have to take one step at a time and crawl, then walk, then run there.  We want to imagine ourselves warping into the future, to the place where we'd rather be.  But it takes time to get there in reality and our imaginations are way faster than time and real-world processes are.

We need to make things happen in reality through our actions and by externalizing our vision to other people and the world around us.  This takes time and keeps us grounded in the now and thinking about what steps are required to execute next.  We have to keep our pace and sense of urgency high (by developing new, more complete and current visions) to get to the future fast enough or it could be gone by the time we get there. 

So be flexible in your vision and let it change because hopefully it will only get better or more realistic as you take the steps to getting there.  Don't just be a dreamer, be an adjuster of dreams to align with reality.

See communications and delivery as separate but a part of the same customer-centric whole

It's all part of the same thing,
we just don't know the difference sometimes
but we have to create and define it.

Most projects are tough because there are two main and competing parts to them: doing the work (adding value) and communicating about the work (selling).  I wrote about these two things yesterday.  When we're in roles like project manager or business analyst, we have to do both and can't focus on just one or we'll fail. 

One time at Microsoft I focused exclusively on delivering the value and failed because I didn't spend enough time on communications and change aspects with the customer (I had no time or willingness to, either, so serves her right...). 

On the flip side, dealing exclusively on with the selling aspects is the same as analysis paralysis and we shouldn't just want to sit there and talk about it all day: that's not the goal either.  So there must be some kind of balance between these two things.

I think we're lucky: Scrum makes communications a daily occurrence through standups and has a standard process and roles for communications.  Scrum fixes the time of communications and gives most of  the time to the development team to do their work.  In the meanwhile, management and planning activities happen in parallel. 

In Scrum there's a clear and defined way of communicating and this is necessary.  Many new projects don't have this structure and need to get it as soon as they can.  So, in summary, we need to have the role of delivery, the role of sales, and then a defined and clear relationship between them.  Get it!!

Think of services instead of projects

Hitting the drum once is fun and nice and all (and important)
but playing a sweet drum solo is really what you prefer.

Projects are a convenient way to think about things: they have a beginning, middle, and an end.  How cute.  But the truth is, though, that we shouldn't want to think about the end because this means no pay and no relationship!  I'm not talking about death or anything that serious here, I'm talking about the end of our projects when the value has been delivered and the relationship with the customers and project team is over.  What I'm trying to get at here is that we should rather think in terms of long term and strategic (at the program and account level) than at the project level. 

All this said, we really can't have long-term and strategic without projects and immediate value delivery mechanisms.  The truth is that most value is and can be delivered through projects but we have to learn and enact ways to do projects continuously and forever for our customers.  This takes teams to do. 

Let's start imagining things that are built to last and repeat forever rather than one and done.  Forget the old-school ways.

Name the project

Even kids know how to tell us what to do.
In organizations we become followers.
But don't.  Be perceptive and share it.

Between all the clutter and crap of organizations there is a project somewhere.  You are the person that has to identify and name these projects.  Without you, there are no projects, just chaos and disorder.  Get good at finding, naming, and talking about projects and what they are.  Get good at telling people about them, getting them excited about them and helping them understand how they can help the project succeed.  Don't be martyr or fall guy for the project but continue to represent and be clear with people on it and the way forward, to a better place.

Consulting is business development: grow two teams

As the main producer,
surround yourself with sales people and delivery people./
Grow two teams.

As a consultant and project manager I realize more and more that one of the primary and fundamental roles is in performing as a sales person.  But I can't do this alone, I need to create and grow a professional and highly capable sales and marketing team.

A big (and probably the biggest) part of consulting is making sure that you get the job done and make the customer happy.  As a consulting sales person this should be easy because you can always blame the delivery folks that the thing went wrong.  But when you're also on the hook for the thing that actually comes out the other end you'd better be really careful.

As a delivery and sales person you have to make sure that you're winning and influencing all of the time: both on the sales and customer side and an the internal delivery side.  It's hard a lot of the time to wear both of these hats but what it means is that you need to build up two teams as the lead consultant: the sales and account management people who support you as well as the delivery people who support you. 

In consulting you are in the middle in a major way.  You have to build up teams above and below you that support you and create cushion and padding so you can comfortably deliver the end product and deflect attacks from difficult customers and the market with very high expectations.

Be the chief framer

Continue framing and flexing the thing.
Don't get burdened and bogged down
with too many details.  Keep changing.

I want to be the chief framer of things.  This means that I want to be holding the thought process that it is the thought process of record, the one followed by the team.  In this way, I want to lead and be the guy.

I want to be able to suggest what is needed and continue to shape and frame the solution as it changes over time.  I want to guide and shape things so that the optimal solution can come out the other end.  I want to be agile and flexible, responsive.

Things change in projects all of the time but with proper framing and an ability to reflect and change, we can continue to be good and create win-win solutions with our collaborators.

How much power we actually have as project managers

Being on top of the mountain feels good, but
there's still sky and heavens above and plenty
of places to fall and hurt yourself below.
Don't forget your true, humble place.

Being the boss is fun.  But its rare.  Sometimes we might think we're the boss but very frequently we are not.  Being a customer is probably the closest we can come to being a boss: "the customer is always right".  I would really like to achieve this level of control on my projects where the buck stops at my desk and what I say goes. But this rarely works.

We should shrink our organizations.  We should centralize more decision-making authority and shrink our work cycles.  But this doesn't often work because sometimes we really do require input and authorization on projects from a very large collection of stakeholders.

So it might be true that "my requirements are what I say they are" but at the aggregate and at the project manager's level, they are rolling up and what the project manager says or thinks really doesn't fly.  The project manager really is just a facilitator and adviser to a larger, far more political, process.

So be careful project managers, although you may feel like you may have god-like powers and feel in control, you're still reporting to your board and you're still accountable to your customers, stakeholders, and stockholders.  Tread lightly and don't abuse the power.

4 key things a project manager must do

According to my way of thinking, there are four key things that a good project manager must do:

1. Clearly define work.  Defining what is owed by when.
2. Assign work.  Defining who owes what.
3. Manage risk in the supply chain.  Knowing what you'll do if you do/don't get what you're waiting for. 
4. Lead.  Using your own time efficiently and effectively to unblock and dis-impede the project (lead).  

Clearly defining work is a key element of being a project manager.  What this means is that you are crystal clear on what needs to be done by when.  The project manager must know the "Definition of Done" and what is good enough from a quality perspective.  In order to do this, the project manager must speak with both the customers and the suppliers of any given work item and very clearly define what's needed.  Before the work is produced, there should be a commitment for each item on the statement of work.

Assigning work is a very important part of being a good manager as well.  Assigning the work is all about getting good commitments and trusting that the resources you have doing the things are quality and committed and for real.

Managing risk in the supply chain is a hard part of the project manager's job.  The project manager has to have mitigation plans for what they will / won't do if they do / don't get what they're expecting.  In this way, a big part of the job is to wait for things to happen but when they do or don't happen be very prepared to act upon the failure.

Leading is of course an overall critical skill that the PM must have.  This takes many forms but in this context I'm using it primarily to mean that you are a good professional and know how to use your time and others effectively.  You are efficient and effective at getting the things done that you have to do (the steps mentioned above) and making sure that the whole thing is tracking.

There's a lot to being a project manager, but maybe thinking about it in these four simple "competency areas" will help you figure out where you should focus your efforts at the moment!!

Basic schema for tracking a project

I’m managing a project/program right now and am using the following basic structure for communications to the team:

• Deliverable Name.  What’s the body of work/thing.
• Sub-Team members.  Who all is working on it.  Be semi-descriptive, “Jim and Mary with Joe”
• Status color.  Red, yellow, green, N/A.
• Status notes.  Be clear about the current status of the thing.
• Active assignments.  The things that people need to do with respect to this item in the near-term.  This should include risk mitigations, escalations and everything.  Everything needs to be work / an action.

In the meeting, we review last week’s list, and update it for this week.  It’s a simple process that seems pretty effective.  As new Deliverables appear, I add them.

Distinguishing between work and risks can be difficult

Risk is a context in which we all live.  It is a reality.  Things we don’t want to have happen could happen, and sometimes do.  We have to plan around these things and work to avoid them.  Much of project work and management is to avoid risks from occurring in fact.

Escalating risks to management is frequently required.  The managers need to be prepared for the things that could possibly occur (the impacts).  People don’t like surprises and by sharing what could happen if risks do happen, you are doing well to cover your butt and prepare people.  (I told you so!!)

As the PM, you need to guide change and make things happen.  You are working your butt off to make the good stuff happen and prevent the bad stuff.  But some risks may be occur and by engaging a steering committee to help you avoid risks or prepare for them if they do occur, you’re doing well. 

It’s impossible to do everything as the PM and by including others—and not necessarily asking for help—but telling them that help *could* be needed, you’re doing the best you can.  At least they were informed and prepared for possible realities.  I told you so!!!

Linking to the ‘new’ form for Work Items in TFS 2010

A customer asked me to create a link from his web site to allow users to create new TFS work items.  Here’s how:

1. Find your TFS web client.
2. Create a new item.

3.  Fill out the form as you’d like it.

4.  Click the ‘Copy Template URL’ button.

5.  Have fun!

The Release Manager is the Product Owner

What's a release manager? A marketer. A public relations fellow. Someone that cares both about the customer AND the product development team but in no specific order. This person is the best possible person you could have on your team or company. They can turn a bad project into a good one and a good one into a bad one. If you have someone acting in a release manager capacity that is either A) all about the requirements or B) all about giving the customer everything they want regardless of cost, you're in trouble.

Train people in this role how to help you out, provide air-cover, and also how to serve the customer. If you are the guy/gal responsible for delivering the product find someone who complements you very well and understands how to communicate, deflect, and the like. I'm not yet sure if the Release Manager needs to be technical in a software project but I believe the answer is definitely yes, since if they aren't they can't deflect and backlog as necessary, that would end up falling to you.

Developing the Right Metrics Matters the Most

There are several ways a person could view an organization:

• As a collection of business processes (activities) that the business has to perform to meet its strategic objectives
• As a collection of IT applications that support the processes
• As a collection of people and suppliers who provide the resources necessary to achieve the organizational objectives
• As a collection of metrics or measures that describe the performance of the organization

Although each of these perspectives is equally real, only one is RIGHT in my opinion. Which one? METRICS, I say. Unless we boil our organizations into numbers and shared things that people can understand -- not complex and changing things like systems, processes, tools, and people -- can we really manage our organization as a program. I'm not making an argument for ACCOUNTING, per se, I'm talking about those facts and figures that tell us whether or not our business is being successful at achieving its objectives.

Therefore, it's my contention that a key part of the strategic planning and communications processes is to define and communicate about the key performance indicators (KPIs) of your business. KPIs are a bit of a cliche term but they're critical. The fundamental question we have to agree upon is, "How will we know that we are doing well?".

The more we develop this language of numbers and measurement, the more clear we will be together on our perception of what matters and how to allocate our resources and attention.

Replacing Problems with Solutions -- More thoughts on Pragmatism

After I published my last article “15 ways to be more pragmatic at work” I started to wonder if I’d overdone it by citing fifteen points about being pragmatic. Maybe I personally wasn’t very pragmatic since it took me fifteen points to make my case!

When I wrote my 15 points, the problem that I was trying to solve for was that for me the idea of pragmatism seemed very complex and I felt that I had to create an equally complex solution (one that required a fifteen-point process) to solve for it. The basic point here is that pragmatism has a lot to do with efficiency and perception.

If the input requirement I'm given is “build a box” and I create something wildly complex like a computer, you may say that I wasn't being very pragmatic. Whereas if I instead drew a box with paper and pencil and you liked it, you may say that I'm rather pragmatic. It all depends on how we define the problem, who's the audience or judge, and what's really at stake.

When it comes to making new things and getting the most out of life, all of us probably want to know what to expect before we take something on so we are prepared to advocate or defend what we’ve done once we get to the end. We don’t want to do anything without a purpose or to have a story to tell! We know that we won’t be able to mitigate all of the risks involved in doing what we want to do decide to choose the most important risks to mitigate and go down the road to fixing them. Along the way we may have to defend our actions and tell others that what we’re doing is the right thing and the step we’re taking is the right one. In others eyes, we want to be seen as capable, confident, and intelligent; independent.

A pragmatic solution to me is one that includes only as much complexity as is required to be deemed by the people who defined and/or are defining the immediate problem at hand as acceptable. To provide for this we have to know what expectations others will have once we’re finished. This is why we have to inquire and wonder and include others on our journey. This is why planning matters and this is why it’s nearly impossible to create solutions in a vacuum.

Let’s set our sights on replacing problems we have with solutions we like.

Managing Schedule Risk in an Agile Scrum Process

Managing time and the team in an agile scrum project is difficult but it's gotta get done. In all projects, we have to estimate what we're going to do and try to get it done. If we aren't getting it done, we have to either work more and meet our deadline or communicate to our sponsors how things are going to be different at the deadline or move the deadline out. It's all about delivery and customer service in the end. At any rate, typical software projects have two distinct parts, each requiring their own management techniques:

1. New feature development



2. Bug fix, customer service and support

Since we have to manage both of these types of work, and they behave very differently, we need to develop a language around getting things done to support effective communications within the delivery team and to our customer community. The choice we use at my company is Agile/Scrum, where we plan and deliver our work in 2-week increments called sprints. By doing this we're able to execute and significantly re-tweak our process every two weeks. We are given a quote-unquote new lease on life every two weeks; it should be a refreshing way to work and partner.

In our methodology, new feature development is handled by the Agile/Scrum methodology burndown method to track work. The burndown method is the typical agile/scrum way of tracking work: we create a definition of done in terms of scope and features, then estimate how many hours we think it will take to do it. Between the ScrumMaster and the team, we track how the hours are burning (up or down since maybe your last estimate wasn't great and there was unseen work) on a recurring basis and if we think our velocity is what it needs to be. If the velocity starts to slow down, the team addresses how to remove impediments and get the velocity up to such a degree that the project is scheduled to finish on time. If things don't go well, we figure out how to mitigate the risk with the customer.

Burnup is a different but important concept to understand and use to manage our work. Our example of using burnup here is a 50-hour max promise to the customer to deliver customer service. We don't have to provide all 50 hours in our example but we do want to know how much of this time we're spending because it's a distraction to the other part of the project since we can share resources and sharing resources is efficient. This method requires tracking ACTUAL hours spent, which is different from the burndown method. Note that this is a key difference from burndown, where we really only care about how many hours are left. We can see how many hours are left on a burndown type of project but what's potentially left on it is certain, whereas what's left in burndown is only estimated.

These two methods of burnup and burndown are two very different ways to think about work: the former is a picture of what's necessarily remaining and the latter is a guess of what's left. The latter is best mitigated by good planning and knowledge of what tasks and how much time is required to get to "done". Together, we use these two techniques to manage risk and communicate effectively.

Conclusion: We Can Now Manage Projects That Burn Time Up and Burn Time Down

By understanding how these types of work are different and how we can manage each, we're able to develop and speak a language about risk and progress making our velocity increase and our projects more fun.

How to Continuously Improve

Deming tells us to plan, do, check, then act. Is that all there is to it? Yes. But it's not that easy for a lot of people to do this. Why?

In more detail, here's the algorithm I use:

1. Plan a project or action based on your conversations with powerful and legitimate stakeholders.
   
2. Do the project or action according to plan. Do not deviate. Almost always there will be a gap between what was expected and what actually happened.
   
3. Check how big this gap is. Get feedback from the stakeholders. Note what to keep doing, stop doing, and start doing for next time. Make a plan to support what you want to keep, stop what isn't necessary, and start what's required.
   
4. Act on the plan.

Does this work for you? How do you modify this or do it differently? How does technology affect this? What tools do you use to support this process? Is there a different process? What is the hardest part about this? What makes this process break?

Program Managers and Product Managers. What's the difference?

I recently had an interesting conversation with a friend of mine who works at Expedia as a Product Manager. He appears to like it. For comparison's sake, I think we're different in that I have been a technical resource for a number of years and get the engineering side of things perhaps better than he does; I've been a developer, I've built many web sites and software applications from scratch, so I get this engineering-type stuff! The thing is that I think I also get the customer side of things very well, too. I've been making solutions for people for over 10 years and have applied many leadership skills, Voice of Customer, and Use Case / Process Modeling techniques when working with my customers to ensure clarity and quality. My point is that I think I can do either the job of Program Manager or Product Manager but want to pick one. So which one?

Program Manager: I have a technical background. I have been a software, database, and process developer for years. I like the technology for the most part but don't want to get bogged down in too many technical details. There's cheaper labor for that type of stuff! I'd rather manage. I have been both a project and program manager for software and process implementation projects within Siemens. I enjoyed the control of those roles and got to do much the Business Analysis and Product Management efforts on those project, too. I had a really great gig and didn't even realize it. For me in those jobs, the hardest thing to be successful and feel happy was communicating. I've learned some hard lessons and it's really tricky! Respect and "yes, sir/ma'am" go a long ways and force is rarely a good tactic. As a Program Manager you should have a lot of pull and influence in the development organization but functional organizations beneath you in Engineering often get in the way of that. In this case, it's not always about working with the workers, it's about working with their managers...and that can be tough.

Product Manager: So it is definitely my goal to be very customer-driven in what I do. If it weren't for others, why would I be here at all? I want to make products that are for people and valuable customers. I love working with the customer(s), understanding their needs, and working with them, the development community and engineering to define an elegant and cost-effective solution. This is the job (or should be) of the Product Manager but the rub comes in that I've recently experienced Product Managers or Business Analysts not being valued (sure this isn't new) by the development organization. "Oh those business people don't know." But in my case, it simply isn't the case because I do know. In this last case, I appeared to know more about the technology than many of the technical resources. In many cases, they're hired guns trained up "just in time" to solve problems. I'm not going to be the one implementing but they sometimes didn't even get the concepts I was using.

To conclude, I want to be a Product Manager so I can care about and work with the customer to understand their needs AND heavily influence what is built (Program Manager). Do I need to choose one? Is there a hybrid? Is the only way out of this quandary as the CEO? Should I work for a smaller organization in hopes that I will find this hybrid?