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.

Scrum - can it really be useful for short duration gigs?

Scrum as invoked by pioneers like Ken Schwaber is super useful on projects that extend into multiple months with several layers of use cases, controls, and middle and backend tier work. However, with short duration projects, the concept of the sprint and the backlog are difficult to quantify and certainly even more painful to institute in the org without two things - a strong Technical Team Lead (TTL) resource to guide the project team and an easy to use Scrum subset that works for your environment. If you're a UX centric shop or perhaps a pure development shop and you're plugging into a 3rd party's software project, it can get a bit trickier. Despite the burdens, the key is to be sure that you act with the team and moderate these scrums. They should happen at the beginning of the work day, and if you have a global team, you should consider scrumming at the beginning of your local team's day and at the beginning of the remote team's day to assure that progress is being made and that blocks are removed immediately. Quality increases by about 200% if you have the means to supply a TTL to oversee the local team and a TTL to oversee the remote team. Of course, be sure that only one of them acts as the primary and makes all technical decisions for the project. Moderation of the scrum is not the simplest task, and I must say that getting the project team to feel comfortable during these short meetings is vital. Ask them a) what they have done since the last scrum?, b) what do you plan to do between now and the next scrum?, and c) what impedes you from performing your work as effectively as possible? Time limit should be <15 min for this meeting and everyone must be present. Scrumming has side benefits as well - it helps everyone see the estimation process on the execution side, it helps team members realize time spent across various tasks to better produce estimates in the future, and it makes everyone accountable when the PM employs Scrum correctly. Not to say that Scrum has any written rule outside of its core foundation, but it can turn into unnecessary noise for the project team if executed improperly.

When to sell the design concept and the UI?

Software often gets into a rut in two key areas focused around the UX layer - this is entirely true across .Net 3 and its subset Silverlight that utilize the power of xaml. First, an interface designer shouldn't be caught up on the nuances of window chrome, positioning of elements, or refinements to gradients, flashiness, or hotness when first designing visuals for the project. Ideally, the resource is able to stay well clear of refined comps and focus purely on color palettes through mood boards and simple mockups that combine logical layout with some loose styles. Of course, this requires a decent set of wireframes that should be constructed by the Information Architect type resource along with Use Cases if needed. Building Use Cases may not be required if you're facelifting an app. Along these lines, the wireframes should by no means impose look/feel, composition, or layout since this can often lead to the removal of creativity for the Interface Designer - if this does happen, it can lead to poor design. The Information Architect and the Interface Designer should be locked at the hips at this point, each making recommendations on the business sense and creativity/innovation of the visuals.

Mockups should be very loose - I think of Kathy Sierra's older article on "How 'done' something looks should match how 'done' something is" as a great reference at this point. I particularly love the Napkin look & feel - it just feels so relevant to me. You can't sell the entire screen at once, and it certainly shouldn't be expected to rise from the ether. Several concepts could be presented this way each of which has its own good and bad. I guess I'd say distilling the design down slowly is much more efficient and innovative and will prove the power of this notion with clients. Since the goal is not to stray too far from the approved concepts and interim milestones are met. And just because you have a wireframe doesn't mean that budget should not be available to combine visuals with business value and innovation. I think this is too often forgotten, since a highly polished comp lends folks to believe that you're "nearly done", right?

Another critical point that is an entirely huge topic is that of technical feasibility of a said design - in WPF, Silverlight, assuming you're going for a pure xaml UX layer, you've got to assure that the designer either works inside of Expression Designer, or is mated to a technical engineer or Integrator type resource that can validate a designed UI can be realized inside of xaml...

In summary, selling the concepts of the app's interface should only happen through quick and dirty mockups that take the wireframes to the next level. Once approved, iconography and a fleshed out interface should lead to some early comps that don't go too deep in visual beauty. Experimenting with the animation side of things for the chosen interface should happen in small, self contained little motion tests to prove or disprove the visual concepts. This can get very expensive if not managed tightly though. Only those concepts that are chosen should lead into solutions that get plugged into the UX layer. In the case of using xaml, you should make the determination at kickoff on the UX integration strategy to be used.

Under promise and over deliver seems so obvious here, but it's a double edge sword - are we selling the power of the platform through stunning visuals or are we trying to test the waters and get buy in on the design direction, or are we trying to refine the interface...know where you are in the process and have a workflow that makes sense for your team. As a PM, you have to stick to it, and keep iterations to a minimum to stay whole. It feels like I could go on forever on this topic...another time.