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.

Other people's code

A good read from Thomas Lewis from Mix Online.

http://www.visitmix.com/Opinions/Why-Does-Your-Code-or-Design-Suck

I love the drive-by tweet metaphor from the article...it's so true. And not necessarily just from the design side; it's apparent in engineering, too. From a project management side, this can be quite harmful to a project since the shared goals of delivering on time and making a happy customer can bring unneeded chaos for the project and its team members. My way or the highway just can't cut it in all situations. This is especially true if you're bringing on new team mebers into a project. You can't break down the walls and start over - there's simply no funds for this scenario.

As a PM, create positive outcomes for the project by preventing OPC-syndrome by way of a few must-have's;

1. Brief the onboarding team members as to why they've been assigned the project, what are their goals, their mission, and what framework do they need to work within to assure project success. This is not always "perfect" success, but we have to ship software, right, and budget doesn't grow on trees, especially in a consulting org.
2. Bring the correct resources into the project to perform the work. Tasking an Integrator to define a better UX metaphor will only disenchant the creative team - that's their job!
3. A senior developer needs to establish and lay down the application's architecture - don't expect devs to be happy if they're being tasked to super clue fixtures to a solution. On the flipside, we can't afford to overarchitect some fixtures for the sake of ego - ego my Eggo.
4. Critique and feedback is welcome from within, just be sure it's well organized and not flung hapzaxzzardly to the team - the peanut gallery can get ugly. Put a forcing function to funnel feedback through someone so the trivial pieces are diverted from the team. And raraly in a UI/UX driven project is there sufficient time to sit back and iterate and iterate on the deliverable. So, there may be a week left till final delivery when the completed experience is put together. Encourage the team, and take the flaming arrows with your trusty shield. Conversely, don't ignore internal feedback altogether. That's not my suggestion - working peer relationships only strengthen through listening and learning.

Cool Silverlight stuff

This Sobees social networking client ported to Silverlight 3 - don't forget the offline experience avaialble from the context menu. So fast and clean. Nice job, guys.
http://www.sobees.com/

And this beautiful nugget in the banner area front and center is built atop Silverlight 3. Parallax panel to the rescue with smooth streaming media and a slick flip animation sequence.
http://www.microsoft.com/silverlight/

A good article on why to wireframe for your project

Good read from Thomas on visitmix.

http://www.visitmix.com/Opinions/Should-We-Kill-Wireframing#200905140354378

For Rich Internet and desktop applications, rectangles, buttons, textboxes, and breadcrumbs simply don't do it for wireframes. They serve to ground the logic flow of an experience, but for this low-degree of effort, it's not reasonable to assume that your client will understand or even what you've come up with here. There is truly a balance between visually sound and agile prototyping. To make a bold statement on a unique UX for a particular scenario will win over a client's trust in your abilities. Still, we can't expect that every scenario will have that special user experience or we'd all be broke, right? We need to wireframe what is absolutely going to be a pain point for the client. Sketch quickly, prototype the design collaboratively, and best of all, if the client is unable to accept how an interaction will take place or how that flow of information will take place, lean on an animator to stitch together a few keyframes to illustrate the pitch. Make it quick and dirty, but most importantly, pitch the right UX metaphor for the interaction. Sell the wireframes on the key moments, not by designing a black/white web site. No matter how cool Sketchflow and other tools sound, there's no substitute for back of the napkin, whiteboarding. Still, if you pitch a wireframe, you better be sure the client knows if it's been blessed from engineering or not.

Good talent can actually be had

IdentityMine is truly on the cusp of greatness. Some of the finest visual and creative designers I've had the pleasure to work with are noodling forward on concepts and ideas that are both very interesting with good business sense behind them. I love my job.

Planning for Microsoft Surface

Rarely in the past has software development hit so many avenues. Microsoft Surface provides methods of reaching users previously unexplored. There's always something to be said about good project planning, but in this realm, you've got to nail down not only teh basic logic of the app, but also the visual feedback presented to the user as well as audible feedback - it doesn't make sense not to have sound employed. Introduce loads of risk into the solution if you don't have a good backup plan for just about every UI element when schedule is compressed. Showing off technologies like this requires patience and a team willing to take quick dives into feasbility and the PM knowing when success is possible or diversion if needed. There are accept states, deny states, active states, click states, hover states, drag states; there are gestures embedded within controls that require special architecture/finesse to construct.

And all of this needs to lie neatly into a package of work items with little specificity between Dev and Integration. These are good times and workflows only get better as a team gets more experienced.

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.