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...

Utilizing resources in different ways in XAML driven gigs

As a Project or Resource Manager, you're often faced with a reoccurring dilemma in UX driven projects - that of putting the time in to clearly define dynamic styles, screen transitions, control initiation/dismissal, button styles, etc. Don't forget to plan for this in the workload - ideally, you get time from your information architect to depict logical wireframes that make up the UI and identify the use case(s) that need to be satisfied with the solution, and you've got the creative team working to produce design compositions depicting look/feel of the various screen elements and its backdrop. Even better, you set in motion your creative designer and information architect, or BA, to put together a clickthrough slide deck that describes the flow of the application - this can just be a simple PowerPoint deck where you drop in the comps and provide the "Arlo Guthrie" effect (I call it) where the circles and arrows and a light paragraph describes how the app will support the wireframes and use cases...OK, so big deal, you say...let's jump into implementation, right? I've got my pile of approved comps and I've got data to work with, let's go.

Wrong! My point of this post is to simply remind you that there's a crucial step missing if we set engineering in motion from this point. We need to loosely define the expectations of each page transition - how should the screen transition when called...when dismissed? How about the controls that will be needed? How do we expect the controls to be spawned? What's the feel of the app? What's the target audience of the app? What's the target resolution for the app? Loads of questions should be asked here to assure that we put some creative thoughts into how such transitions and styles could be employed. Really, there is no right or wrong answer, but some thoughts should be gathered for each dynamic element of the app in the form of a bullet list of text. I've been calling this motion architecture - we need to describe the motion of the visual elements in some way using human words that help a Design Integrator implement a solution to solve each demand.

OK, so how does this align with the title of this post? Cool, you're paying attention...take advantage of many of your resources - you don't need to find your Expression Blend person and say, make it hot! Consider the designer who can do some motion modeling in his tool of choice - don't ask for an implemented solution here, we're merely searching for that new look, the new sleek metaphor that hasn't been abused elsewhere recently. Or consider engaging a resource skilled in hand drawn art to sketch out some cool ways to motion graphics on the screen. The key here is that these are all concepts, ideas that feed discussion. Your Blend resource can recreate what the team finds cool into a storyboard or transform or something that can be really cool. SP1's shaders - cool OOTB visual effects ready to go in the platform for WPF projects - are another option. As the app framework comes together and the pages get stitched, you've also stirred another sense - that of personality. If the app is fun, make it sharp, crisp, and provide a style for everything consistent with this theme that you're evolving at this point. Don't make a hodge podge of effects either into the app since that completely abuses this privilege, but making these decisions up front and consistently in the project sets a good tone for your project team and reminds them that everyone can contribute here, and nothing should be rejected. This goes for the QA team as well - hitting the app during component testing may surface some cool ideas. Get it all documented and kept as an Addendum to the slide deck I describe above.

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.

Strategic or tactical as a PM? Part I

I seem to have read a lot lately on the topic of strategy and tactical planning as it pertains to a Project Manager. I've certainly got some opinions on this topic. First, for software development projects that are of short duration, regardless of the scope of work, it is paramount that the Project Manager fully understands the client's expectations beyond the functional and delivery requirements - tactical planning outside of the execution environment is really key. Being involved in the business development process at the correct moment is of vital significance to me. I need to know what the driving forces are for the client, what personalities exist with the various stakeholders, what are the measurable success factors, what influences your key stakeholders, and most importantly, what are we really trying to solve. The solution itself should be in liquid form during this stage of the client onboarding process, and as a PM, you can help shape this. I'm of the mind that there is a very narrow line between the presales phase and the delivery phase of the project for the typical PM who manages short duration, high visibility projects. If you produce contracts, charters, or SOW's like I do, you know how critical it is to be a collaborative member of this presales phase. Becomming removed or left out of this process not only greatly increases risk for the project you're about to undertake and manage, but it also tends to bring on dismay and distrust from the clients when questions and comments are raised that were already answered, but not documented anywhere for you and/or didn't make it into the SOW.

As for strategic involvement for the Project Manager, I like to consider reorganizing chaos across the organization an eventful way to share the wealth of your position. I'll continue my thoughts on this piece in Part II.

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.

Welcome

I'm a Technical Project Manager and have spent the past 3+ years of my career working specifically in the .Net 3.* arena. I've got loads to share, and look forward to spilling the ins and outs of my trade. And by all means, the community at large is the main focus here. I have nothing to gain but your collaboration on my topics.

Subscribe to this puppy and let's get started.