Keeping the project whole

As a consultant, whether you're acting as a PM or otherwise part of the project team, it's your job to assure scope and effort are monitored. It's not always the responsibility of the project lead, or PM, to assure that tasks' hours are kept in check. Everyone contributes, and must participate in the regular evaluation of the spent budget and work remaining. The PM is absolutely accountable for the spend, but the project team is responsible for the spend.

In a public sector, the PM has to use extra caution because typically these funds are closely monitored and controlled by governing bodies. It's not always easy to generate a change order and there must be thoughtful audit trails applied to assure that these forks in the road can be addressed. It's not the fault of the consultant that change occurs, nor is it the fault of the customer. These things happen, and must be jointly observed, evaluated, and defined before such a path is selected.

In my experiences, the safest and cleanest way to assure minimal ambiguity around such scope changes is by way of a very complete and well constructed statement of work (SOW). You cannot assume that scope will work itself out in the project charter or by way of evaluation of each and every change instance; there must be clear boundaries applied at the contractual level to assure you have the means to keep a project's spend minimal, or at best "whole".

As I've preached for years, a good PM is also a very good legal writer. Whether he/she writes the SOW or works with account management to write the SOW, the PM cannot be absent of involvement here. After all, who's going to use this document? You are, the PM!! If I am going to asked to manage a project, I sure better be working closely with Sales/Acct Mgt to assure that it gets crafted in such a manner that I can definitively work within it to manage the project...

For instance, if we say that there will be requirements gathered from the user population by visiting several sites and that these requirements will define the design, and thereby implementation of such a solution to support all of those requirements inside the body of one SOW and around one cost structure, we're opening ourselves up for unplanned work, and most likely effort that exceeds estimates when dealing with a fixed price gig.

Working the customer to help them understand the project's structure, selecting a path to enlightenment, and assuring that there is sound evidence of this path, expectations, and boundaries living within the SOW, sounds like extra work. But, it will only make both parties satisfied because it will be clear that there is a vast unknown of requirements to gather. Out of these requirements, the customer can prioritize and select those requirements to go after and produce a design to support them. With a solid design and architecture, then the team can go about building it and the project spend has a far better probability of staying whole.

RFP Respons[iveness]

Nothing brings resources together closer than an RFP Response team. Team members are hounded, questioned, examined, challenged, corrected, but most of all praised for a job well done. In the end, a solid RFP Response shows critical thinking and experience in the craft. It's not easy, it's not even always fun, but two-thirds of the way through one of these, I get jazzed and the puzzle seems to fall in place. Quarrels and sleeplessness abound, it is a part time job for most of us, but we need to make the most of our time and impress our customers.

Still learning, but here are some takeaways to share?

• Force engineering and integration teams to work very closely together in the estimation - Siamese would be best :-). Challenge the level of innovation, the complexity of design, and the overall spirit of the completed solution since if these two teams get it wrong, we're doing something w/o a paddle.
• Rely on SME's to assist in the estimation, but don't assume and request the entire org get involved. It's too expensive, and context switching for resources makes it worse. Define an RFP Reponse Team (RRP) and don't alter resources since learning curve is usually very high.
• Just because there's solid RFP details doesn't and shouldn't limit the need for scrutinizing everything - RFP owners expect to answer questions as long as they're posted before the deadline. Put 'em to work!
• Run a tight ship as a PM and consider this a project - a far more critical project than others perhaps since a) you're sucking bandwdith from the org, and b) a painful, incomplete response can lead to dissatsifaction quickly.

Opportunity Phase - How can I add value here?

The Opportunity phase - the process of onboarding a client, discussing potential work, generating a proposal, and lastly, subsequent legal contracts to bind a project.

If I were to write a paper on this topic as it pertains to the PM discipline and small to medium sized orgs, it would contain chapters of details on these five key areas of interest.

1. Help mold the process of onboarding a PM into the Sales process. If you're far detached from the land of SOW's, see if it makes sense to collapse the walls and share the knowledge between account mgmt and project mgmt. And manage the Opportunity phase. BizDev runs around with its head cut off trying to make a sale, meanwhile, everything from BBQ's to widgets to the Grassy Noll is being suggested as scope for a potential project. Get yourself pulled into the process early, not too early since this phase is usually an org's investment and looks like lost revenues when things run amok. Run the gamut - line up proper meetings, task your team and the clients with tasks and make expectations on when things are due. Drive to req's, not assumptions. Don't be a receiver of the SOW, step up and desire to own this process, put together a contract that you personally own, be able to honor that contract since you wrote it, carry the whole project through to delivery. It will make you a much stronger individual, and strengthen your PM skills.
2. Know the technologies in your LOB. Using Project Mgmt in a software org demands a high level of expertise. Don't put off learning the inputs and outputs of your technologies because you think you're fine with your PMI cert, your college business courses under your belt, while you sit and "control" (man, I hate that word) your project in your four inch binder. If this is your persona, then read no more. But if you want to experience more of an org's business, particularly software development, and climb the corporate ladder, you need to well round your self. I'm frequently irked by those with a PM title in software development that haven't the faintest clue of what they're managing. Become an unblocking tool for your team - it's cheaper for you to know the answer than it is to bug Joe who is knee deep in a project of his own. In the Opportunity space, nothing shows credibility than having a PM speak the language, or at least keep up with the demands from the client while trying to put together a proposal.
3. Don't ditch what you think you know and what you think the client knows. Reiterate the obvious to avoid confusion, make use of a work session with the client to assure that everyone verbally hears the demands of the stakeholders and the minutia of what you and your team intend to provide. It's like a good back massage, you can't be expected to leave satisfied if you don't start from the top and work your way down. Learn to become a vehicle of information - not an AMC Gremlin, but something much faster. Data is cheap, it's information, the right information, that gets the sale and turns the opportunity into a project. Help Sales to understand the severity of the situation. Don't dabble in ideas, come to the table with solutions.
4. Don't craft a contractual document just because you think it's time to make a first proposal. Huge waste of time. Make it simple and construct a sturdy, short slide deck, or equiv, that will convey your proposal to the client. Focus on the meat - goals/vision, approach, engagement model, deliverables, and costing. Here, it's a freeform, informal, non-legal binding collection of intentions. Iterate here with your clients until you reach accord. Then, spend the time to craft the contractual document. Focus on this document as a deliverable - an artifact that will get at least a verbal go-ahead to proceed. In line with these thoughts, don't waste time building the project plan, or allocating resources. Too often this happens here, and the thing isn't even sold yet. Time is money!
5. Become interested in client negotiation techniques and contract law. Is creative writing for you? Do you like to put narratives together, vision statements, user scenarios? If so, and if there is a marriage between the Project Mgmt house and Account Mgmt or Sales, consider taking a dual roll. I find no greater satisfaction in generating my own contracts (by way of your internal legal group, of course). The more you write, and try to honor in the Execution phase, the smarter you'll get. Sooner than later, you don't have to try to honor a SOW, for instance. You'll know from experience that a particular piece of language will fly. Who wins? You do of course, since you've boosted your skills. But, the org really wins, since time is money and margins should increase. This one certainly isn't easy to attain without some help, nor is it for everyone. But, if you want to climb the ladder, understanding the details of onboarding a client through a service agreement, generating software licensing agreements, service contracts, subcontractor agreements, change orders, or the trusty Statement of Work (SOW), etc., you'll get entrenched on how the business is run at least from the Services side of the house. Lastly, nothing shows class more than a PM who is very client friendly and a good negotiator. Seek out SOW samples, take a class on contract law...read lots of books on the topics, and see if you can shadow someone to pickup on others' styles. Negotiating is not for the meek, but again, it's truly the means to operational wealth in the org.

In summary,

• Expand your technical knowledge and reach in your LOB.
• Consider familiarizing yourself on the account mgmt side of the house - learn sales negotiating, contract law.
• Become a leader in the realm of onboarding new projects from opportunities.

Crafting the SOW

I've always been a big proponent of the Project Manager being engaged early during the Opportunity phase when onboarding a client and wrapping a project around the need. This is a fun, sometimes overwhelming, and utterly detail-oriented that could bring on the need for some Aspirin after a few heavy days of brainstorming, whiteboarding, and most importantly listening and asking questions.

Fast forward to the development of the Statement of Work (SOW), our formal, contractual list of demands, assumptions, risks, and a schedule that binds the project with your Customer...for software gigs, as a PM you simply must understand the inputs, outputs, and adjacent systems of your project. And if expected to honor the SOW, as a PM, there's no better way to honor the contract then to craft it yourself. Contract negotiation experience, contract law experience, and a technical understanding of the project are all nice to haves, but there's simply no substitute to having written hundreds of them yourself, and having a keen legal review body to watch your back. As a PM in a software consulting house, I believe a serious value-add in such an org where Account Mgmt and Project Mgmt are merged is having a PM that can speak the technical language, has strong business and Customer-facing skills, and who has produced loads of SOW's him/herself with an understanding of what will stand up and what will fail. Profitability in a software consulting org depends on careful project planning, complete extraction of Customer demands, thorough commnication, and finally, a rock solid SOW.