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.

Only make the sausage if they'll pay for it

It doesn't really matter how you make the sausage.
But the sausage had better be good and the customer
had better be willing to pay for it.  Regardless, don't start
making it until you are confident you'll get paid for it.

Sometimes it's really nice in projects to be given the opportunity of an "open" contract but it will frequently lead to disputes if you're not careful about managing customer expectations and the budget.  If you're not a professional project manager, you should not dabble with T&M contracts because you will get burned by hard-nosed customers that demand quality for their money (and they should).

It would be nice to bill people and see if they pay or not but you have to make sure when you're doing this that you're also able to defend your price and value for what you're billing.  This means that you have to have excellent metrics and measurements of the value you're delivering and a justification for that value (the business case and justification, ie the argument *for* the price).

Whether you're managing projects on a fixed basis (even Agile is fixed since it locks scope for an iteration) or on a T&M, more loosey-goosey basis, you have to be careful.  No matter how you're making the sausage, make sure that the customer gets it, is willing to pay, and likes you enough to fork the money over.  Otherwise, you might as well not start.

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.