Designer / Developer workflow

So, I wanted to take a fresh look in the community again to see what others are doing in this space. Specific to the .Net 3+ stack, we've been using various workflows for over five years now, but I'm always curious to get fresh insights as to what works and doesn't work. Visual Studio 2008 and Expression Blend 3 afford some luxuries to solve this dilemma to some degree, but truly doesn't provide a seamless mix of tools and support that fixes this in all cases - let's face it, resources have their own constraints, and we'll have to live with that. And frankly, this is where the breadth of an org's resource pool (when properly distributed with the right roles) really shines. So, I don't want to convey a forcing function to standardize "proper" workflow for both Designers, Developers, and Integrators (if you don't know the meaning of the latter role, at least our meaning, please read Nathan's article on the Integrator here as well as his very straight forward article on integration therero found here) - aka, Deselopers, Devigners.

In my Web travels this morning, I found a good article from Tim Aidlin @ MixOnline called "How we work (and sometimes skip some steps)". From this read, I have one key takaway that really sums up my feelings. "It depends - wireframes are great tools when used properly". And here's a two-fold statement on this behalf. As a consulting org and a project manager, we don't always get the most ideal resources for the job. We make do with who we get, and cater the project around their strengths to deliver results and good success for the client. Secondly, in terms of necessities for taking the design directly into production, like HTML, CSS (or more specifically for us, as basic XAML) assets really depends on what we're trying to solve for the problem at hand. Now, I'm not trying to say that we should toss any old resource at the problem, and getter' done one way or the other:-). What I am suggesting though is that we need to be very critical about how and why we're bringing on a particular resource for the job - an Information Architect from the creative team, vs. an Interactions Designer from the creative team, vs. a Visual Designer from the creative team, vs. a resource with some mix of Integration and Creative skill sets.

Hopefully, I've still got your attention - I do, right?? If we're trying to comprehend a client's issues, we must first have a solid problem statement that defines what our client is trying to solve and to what degree, and craft this immediately into the Opportunity phase of this project. From here, we should be able to deduce which "role type" we need to bring in to help. For instance, if we think taking use cases w/user personas and generating some high level wireframes to solve these needs is vital, you'd better be asking yourself, "...how necessary is this? Will our client truly need a redesign to its existing solutions, has visual style already been well defined and we shouldn't mess with that tier, is layout and general interface design important at this point or already approved elsewhere, can I break ground with my new technology stack, did my client see something cool at some conference and they say, I want. Did you ask, why?" Likewise, if I bring in an Interactions Designer to exploit my target platform by way of motion tests and wireframes on the whiteboard, am I truly doing right by my project because of the list of questions above?

Wireframes should be used when appropriate for the situation. Conversely, despite my remarks here, I am a firm believer that the Information Architect (or he who creates wireframes in your org) needs to set in motion, by way of an agnostic nature, the required flows through the proposed solution. To say that wireframing, in our line of work, inside of Blend or SketchFlow is the Holy Grail is a falsity - I'm on the wagon that says down and dirty whiteboarding and team collaboration is very important. We don't skip wireframes, for the sake of expeditiousness, and take the designs directly into comps using your design tool of choice: Photoshop, Illustrator, Expression Design. I don't want to agrue over which method is best; there isn't one IMO. Introducing visual style, interface, and UX into the mix should happen in parallel with the wireframes. I regress to my earlier statement about using the resources you have on your project...unless truly junior, each resource has its own way of conveying wireframes and working with the creative team to stitch them into interface comps, perhaps even prototyping interactions in 3rd party utilities, or taking design directly into Blend.

Furthermore, have you really decided which workflow method you'll use for your project at hand? So, back to the title of my post...how does all of this affect the developer who needs to be tightly coupled as well? Perhaps we can we take the project from wireframes directly into Blend if we've got a resource capable of spilling out the app's framework mostly in XAML. Next, we introduce the Developer/Architect type build the custom controls necessary to support the design. In tandem with this, the Interactions Designer gets a textual handoff from the wireframer that describes the intended interactions; this resource gets to work building these. Then, the Integrator and the Developer integrates the design into the solution...What about the converse to this (no, not, the "low top, All Stars" you're wearing)? If the solution is going to mimick an existing interface and interactions, why not consider letting the Developer build the core logic, functionality, and custom controls needed to support the "expected" vision in code - doing so with sound architecture and integration in mind along with lookless controls such that the creative team can provide a design to skin it? From here, the Integrator can stitch together the design and polish up the visuals where needed with the creative team? This is a risky option in some cases, and yes, can somewhat distance the creativeness that your team can bring. But if nothing else, I've learned one thing over the years as a consultant...we're not building the solution for ourselves - don't treat the project like a household pet. To reiterate, provide good user experiences and user interfaces commensurate with what the client wants - not your secret fancy for dancy bears and 3D rotations at every corner.

Still, as I've stated in several older posts over the years, as soon as we master this Designer/Developer workflow, I'll let you know;-).

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.

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.

Save the juicy stuff for a phone call, right?

You have matters to deal with for your project, you're short on time, and you want to make a big splash into a long couple weekend. So, drop a bunch of long winded VM's to your clients; they'll love it, right? Nonsense! They'll hate you for it. a voice mail full of information and demands makes no one comfortable, especially when we've all got a lot going on, perhaps managing multiple gigs, and find it easier to react to an email than to deciphering someone's unplanned, gibberish on the phone.

...and while you're at it...

Spend quality time getting the week's status report out for your projects via email. Give your team a high five for a job well done - make 'em feel loved and excited for some much needed down time. Do you know where all of your folks are going? Who's working which days? Who's on point to provide any support, if needed? You did inject non-working days into your contract, yeah, if you intend to disappear for the rest of the week...and lastly, don't be a slimy Holiday junkie, spamming every client you've ever known with another Happy Holidays mail.

Those of us who really do intend to step away, hang up the iPhone, and chill will have enough emails to attend to on Mon morning.

Happy Holidays!
-Paul

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.

Producer or Project Manager?

Ok, I thought this would be an interesting quick blog...over the years, I've worked in environments where the nomenclature of your dept or group was ever changing or just plain unknown. Let's face it, we love to rename everything in society to meet the latest craze. I've been in db development, production, engineering, software Dev...am I a project manager or a producer? In the visual design and graphics space, I'd be a Producer, managing a team of designers performing the work. Since output is visual in nature, I'm considered a Producer of said artifacts, not entirely correct, but in the Hollywood sense, I suppose I would be equal to a Producer of your fav tv show, the guy behind the scenes pushing and pulling, bringing the thing alive. Since I believe Project Management is a set of tools, this feels good to me. Using PM methodologies, I lead an effort to produce the work.

As a shop specializing in delivering UI/UX software solutions, your Project Manager becomes a UX Producer, a user experience producer by trade. That sounds pretty prestigious, just don't let it go to your head if you're in that bucket;). Heck, you get to be famous with you friends if only for a few moments in time. Next step, a Star on Hollywood Blv...