Project Management in the 21st Century

Projects with a shelf life

2011-12-07T16:46:00.001-08:00

Now, there's a concept...but for many of us, we're left implementing a solution atop a partially immature platform. There's money to spend and time is of the essence, so gimme something now!, is the mantra. Still, as a consultant and technology liaison for customers with little to know in the space, it's in the best interest to assure technology solutions sit squarely within the reach of the customer's IT expertise if they intend to own the product at turnover. Moreover, it's simply not feasible for most to expect to ramp up 3-5 fold in order to take on a new system that requires a massive shift in support.

Be fruitful with the customer and be able to sharply explain the good and bad of technology choices. Recommend the right solution, and don't settle for less. Of course, your customer is always right, but help educate them...help them make a better decision, help them with proofs of concept to sell to higher management....make them a salesman for your services.

To he who says software has an 18 mo lifecycle and must be replaced is just unfair I think. There's plenty of working implementations out there in .Net 2 and 4 that exhibit higher customer value with minimal support components. All important is the role of technical architect on the project. Fail this milestone and you're done for. I guarantee it. I want to revisit this topic next.

SOA what?? Part II

2011-11-13T22:08:00.001-08:00

OK, so it's been nearly one yr since I posted Part I...pretty crazy I didn't consider doing a series on the topic. Anyway, here's some further discussion about the concept of Service Oriented Architecture...

First off, traditional web client applications can rarely be generalized as a thin web client. Like MS Silverlight, what you end up with, using a set of solid WCF services to harness the backend is nothing less than a SOA application taht just so happens to front a rich interactive application (RIA) interface. Calling a Silverlight or Flex app a thin client is akin to wearing a McClaren jacket at a tour through the Maranello factory. So, SOA in and of itself is merely teh notion of using an agnostic set of services that perform complex business logic; the front end application merely consumes what's thrown at it.

Consider your fancy new Silverlight app using Entity framework and WCF services throughout...you've got adjacent customers that could surely tie into those services and solve their own sets of business needs. Data Exchanges are merely a consumer of SOA - such an interface (or exchange) can be created through simple WCF web services or through more complex varieties.

Imagine that Contoso Shipping has this new Silverlight application. Consider the various adjacent systems that interact with the shipping provider. The distributor to the cardboard box maker could use a look-see into your organization in order to know when to send more boxes to you. Our cardboard box maker company uses its own sophisticated, local software solution for its work mgmt, and isn't about to create something and get the shipping company to expose its data.. Instead, our shipping company merely partners with the box company. In doing so, a service contract is setup and those wcf services that provide the interfacing needed (likely existing services that already poised doing other work) are directed out through this new web service. The box company has the bulk of the work from here - they need to extend their local solution (system) to consume these services, transform the data structures coming across and do some analysis. The output sends data points to their system, all the while the system of record remains internal to the box company, but the shipping company gets real-time data from the box company about its # of boxes coming, etc, etc. Make sense?

In this context, a service oriented arch exists that can be consumed by other (dozens) of client applications in order to make use of the data constructs. The service provider merely exposes and publishes its web services to get at the data, and its approved partners get access to the data for consumption, etc.

The interesting part is that of the analysis needed up front to properly put business and technical req's together to facilitate a) exposing a usable service for potential or known users, and b) providing the data exchange using a broad enough declaration of services that can be consumed by the masses. The last, most complex part is that of reconciliation - either the servicing party or the client party must be responsible to resolve data issues that can and will exist between the two parties. In my opinion, it's always easiest to put the burden on the client (consumer of the services). But, this depends on your system of record...if the State, let's say, exposes criminal data to the state counties for use, it likely expects that this is the system of record, and all such edits need to exist in this single system. So, as the State body, we can't expect that the counties will update this system in a fire and forget mode. Counties need to resolve conflicts in the data, e.g., you send me this, and it doesn't match my interface schema or conform to its pre-justified rules, it's kicked out, and you fix it...or, you send me a case record, but some pre-requisites fail, we abort the data exchange, and the county must resolve. The state in this context expects that the local agencies get good data into the system. One step further, imagine the local agency being satisfied with its own local system; they merely have a data entry person stuff data into the system of record (the statewide data stores)...if this person puts bad data in, they resolve it. If not, garbage in, garbage out, especially when in a case like this, reporting is so critical.

A first experience with NLP (Neuro-Linguistic Programming)

2011-02-03T11:35:00.000-08:00

A good friend introduced me to this concept by suggesting a give it an honest try. I'm in a good place with myself and decided to have at it. Leaving the session on Tue, I felt changes and the next day I noticed those same old, ugly thoughts that had plauged me in meetings, during interactions w/colleagues and bosses, and in home situations were a lots less stressful. It is truly from within that the NLP thing works, I get that. I have to believe and continue to see and act on the transformation, but honest to goodness, I thought this was hogwash at best going in. I had to be completely vulnerable and thankfully I did;).

John Grinder and Richard Bandler founded the NLP methodology, it appears, and I am soaking up bits of it this week from the Web.

My personal style of learning and adaptation has always been through reading, reading, reading, and reading some more....then writing it all down for absorption. I really see now how past experiences that have binding effects on me can be altered - not brainwashed, I guess - bu made to contain these new "resources" rather than the old junk. I guess I harvested out the old garbage and implanted anew. That's the best way I can describe this. The gal I worked with for those several hrs sure knows what she's doing and I appreciate that whole journey.

How do I blog about this stuff, this intimate stuff that's unfolding, and make it apply towards my goals of this blog? I'm starting to figure it out.

I'm halfway through Crucial Conversations...a great text. I'm actually listening to it in audio form. I am not a very good learner in this format, so we'll see. I like to see and feel the words on the page or in a document on my iPhone....nonetheless, this is another bit of homework I've given myself - this book, that is...

To want growth, you have to believe in yourself

2011-02-02T17:53:00.000-08:00

I'm shockingly learning more about myself as I get into my new found kick (for those unaware, I've sought professional support, coaching, if you will to help my personal and professional power)...I had a very interesting experience last night that honestly helped unlock past emotions to really surface why I am a certain way - feelings and events that led to what I am today - an almost 40-somethin' character that realizes (luckily) that I need to change how I react to professional settings and how I can enrich my life as a father and husband.

It sounds kind of cooky, I'll admit, but I just have this sense of value, worth, security, and compassion that I couldn't explain a few days ago. I need to learn more about this thing (we'll call it for now), but I'll share more in the coming days. It's truly life changing - one building block at a time. But, I'm open, vulnerable, and willing to adopt change, spill my guts...I want to feel better about taking on new challenges in life, learning how better to negotiate with clients/peers, being a better role model for my young daughters, a better hubby, and advancing my career.

Is it an early midlife crisis, this life coaching desire? Nah. But, I'm thankful to those nearest me who believe in me and for me having the guts to believe in myself and reach out for external support. Pretty awesome discoveries so far.

Still seeking an old book called, I'm, OK, You're OK. I'm reading Crucial Conversations right now. Love & Logic will be next.

A novel idea! A novel about Project Management

2011-01-30T22:42:00.000-08:00

I just finished (today) a terrific novel (of all things) called "The Deadline - A Novel About Project Management" by Tom DeMarco. It's a 1997 read that absolutely blows my mind. It considers basic principles of management in ways and in relationships I simply didn't consider before reading this 300 pg short book. The author illustrates in first person prose in real terms how to put simple change in place - and we're not talking about PMBOK 4 101 here....

The author gets into intimate details about where problems in projects (systems) reside, how to solve them, and more importantly for me, shows you how it's really done all within the confines of a myriad of characters, actions, and personalities. This book illustrates quite openly about how management involves four key things: heart, gut, soul, and nose...among many other great points that the main character collects throughout his tour of duty. I'll note those in a future blog post (I tend to take notes about my findings to paper since I don't memorize key points in books as easily). I know someone that sure can do this though...like a human journal, he is!

But for now, take my word that this book is as relevant as ever. Tom even has some keen insight in this era (some 14 yrs ago now) that is spot on with today's complexities building and deploying software. That Lahksa Hoolihan character is engraved in my head - engaging, cunning, and beautiful all in one;).

Taking myself from adequate to extraordinary

2011-01-30T22:25:00.000-08:00

Alright gang...I finally bit the bullet, and I mean bit-down-hard.

I'm officially on a book kick and I've got self-motivation on the horizon where ever I look...So, I'm jumping in with both feet, with the following two goals solidly on the front burner.

Number 1: Evaluate myself. Where/how can I achieve better results in my personal life and in my professional career? How can I learn more about the inner workings of really being a "Manager". I can only do this with some serious reading - not just books I've read, but a barrage of books on several different levels - books I wouldn't think of picking up one yr ago.
Number 2: OK, so I finally self-admitted that I need a coach, a Life Coach. No..A Motivational Coach. Well, sort of. A Personality/Attitude Coach....Well, close, I suppose. A Leadership Coach...yes, that sounds closer, I think. Maybe counseling to help unlock my "strong adult" vs. my "child"...hmm, that sounds eery, like a need a shrink or something.......I don't know what this goal is exactly yet, but I know I need professional support, a real person able and willing to guide me on my journey, someone I see biweekly or more and someone I confide in for support.

I'm excited, nervous, slightly overwhelmed, but giddy like that first day back in Grad school in a Dynamics of Social Relationships course. Let's see where this takes me. I've already jetted through a great book and I'm seeking a life coach next week to see if it's the right angle for me...

Native screen snapshot recorder inside Windows 7

2011-01-26T13:44:00.000-08:00

OK, so I was blown away this week by a feature inside of Windows 7 that frankly I had no idea existed...it's one of those hidden treasures that's not visible or start menu or searchable unless you use terms like, "snip", "steps", "recorder"...It's called Problem Steps Recorder. I've been using Windows 7 for 2 yrs now (or something close to that while on the beta program) and never realized it was there. That was definitely a RTFM dummy episode, but I'll survive.

Off topic...ok, so I'm a huge Microsoft OneNote fan, and I was looking for the native screen clipping tool that ships with Windows 7 for a colleague (BTW, that's called Snipping Tool). I don't use it because I love the functionality and clarity of capture provided by OneNote's capture utility and integration thereto.

OK, this utility, Problem Steps Recorder is now available on most legacy OS's as well: http://www.microsoft.com/downloads/en/details.aspx?familyid=B72D3AC2-4352-4184-9992-E122DBB80883&displaylang=en

This thing lets you hit record, perform any array of steps on your desktop, add textual comments where ever you like, and press stop to generate a web archive (.mht file) compressed into a tidy zip. And this is an enterprise-ready solution as-is. Starting the web archive file spawns a detailed collection of image snaps and human readable commands performed during the session, not to mention an incredibly useful slideshow view, all in the browser. Microsoft got it right on this one! You can even define the granularity of screen snapshots captured and whether or not to include the screen image (for private data scenarios). Most important to me is that it's lightweight and fast.

With the Silverlight plugin, you can get a quick demo here: http://technet.microsoft.com/en-us/windows/dd320286

I can see huge advantages for QA resources creating an archive as needed to satisfy repro steps for the developer/designer resource...huge time saver, and with team foundation server 2010, this zip could be attributed to a bug item for posterity. I'm probably behind the 8-ball, but I'm stoked about this little gem and will be trying it out with my team.

Keeping the project whole

2010-12-20T10:53:00.000-08:00

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.

SOA what?? Part I

2010-12-17T11:24:00.000-08:00

Been a while since posting to my blog...whow knows what SOA is? I can tell you that's it's a powerful set of methodologies that serve many benefits. Most obvious is the way in which information can be exposed and avaialble for consumption, consumption far beyond just storing data, but building solutions that integrate with this data sharing concept in the cloud.

Exchanging data, or the concept of the data exchange, is a very cool way of making your data available; in turn, a consumer of this data can do something useful (write an app that uses this data to solve a business imperative, for example) with it or simply be a subscriber of it.

The interesting dilemma for an organization today is not in the creation of such a data exchange - this is the rather simple part of hte equation. We can stand up data exchanges all day long that expose information - albeit, there is a tremendous need for clean data, so the backend must be able to support this or some large data scrubbing effort is probably needed. The difficult part is writing or extending a client solution to consume this data and do something useful with it - the "work". Understanding business processes in that client organization and how this newly exposed information can be used to solve them requires time and money. It's ever apparent that most organizations simply do not have existing records, documentation, goals, and needs well documented to understand where in the current processes these calls to the data exchanges could/should be made in order to solve the business problem. This is where the bulk of the effort and work lies, and this is where a skilled team is needed to consult and help strategize the how/where/when/why's of hooking up to a data exchange. This requires business analysis, domain expertise, data architects, and tight inclusion of those stakeholders exposing the data to the exchange and those stakeholders expecting to utilize this data to do work.

Moreover, think of the complexities involved. We need to determine the granularity of such an exchange - to what degree is a business capability exposed - is it super granular such that the message interface (xml) is very narrow allowing getting minute pieces of that data structure (age, birthdate, last violation, etc) or do we provide an aggregated exchange, but also bloat the size of the message interface. Here, we could establish a capability to Add a Debt Collection. This could involve associating a person, a debt type, a payment type, a debt amount, etc.

Summary for now...a data exchange is a good exmample of the SOA software strategy, but it requires much work during planning of the data to be exchanged, but most importantly, requires tight integration with consumers of such data structures and even more so a deep understanding of how current or future solutions need to be written to successfully consume these exchanges - pushing work out to the cloud, while also utilizing this data to solve business problems.

...so what does SOA really mean? More on that later...still unsure what the acronym stands for? Ok, it means Service Oriented Architecture. Come back for more discussion.

Designer / Developer workflow

2009-08-06T16:30:00.000-07:00

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]

2009-07-16T00:18:00.000-07:00

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

2009-07-10T16:45:00.000-07:00

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;

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

2009-07-10T12:07:00.000-07:00

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

2009-05-14T00:59:00.000-07:00

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

2009-05-13T22:53:00.001-07:00

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

2009-03-23T20:06:00.000-07:00

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?

2009-01-08T23:55:00.000-08:00

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.

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

2008-12-23T15:50:00.000-08:00

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

2008-12-18T20:17:00.000-08:00

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?

2008-10-17T17:26:00.001-07:00

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

2008-10-15T23:52:00.000-07:00

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?

2008-09-28T23:46:00.000-07:00

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

2008-09-10T22:57:00.000-07:00

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?

2008-09-10T11:40:00.000-07:00

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

2008-08-27T22:29:00.000-07:00

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.