One of the interesting things about WPF apps, and Silverlight 2.0 apps for that matter, is the number of ways to go about constructing the app. A Designer type can put together an app inside of Blend and integrate design assets as they're built, but then the Designer is blocked waiting on controls or events from the Dev. A Dev with understanding of Blend could put together most of the project and handoff to a Designer Integrator to implement the design assets from the Creative team. Or a Dev could construct the app's architecture, lay down the controls built to support the necessary functionality, and let the Designer Integrator style them - this removes the Creative team from the workflow and is not very smart most of the time. The bottleneck on this platform is often times the Creative Designer since they're often blocked by the Information Architect who is trying to gauge the correct wireframes to suit a select piece of functionality all while working with the Technical dev, the Designer Integrator, and the PM to validate not only the concept's feasibility, but applicability inside of that space...repeat dozens of times for a given project. A challenge for a PM is to assure that all resources on the team fully understand which workflow is going to be used and sticking with it. Still, it's hard to measure progress linearly. The critical path is the Information Architect and his/her ability to swiftly move through bits of functionality. In a perfect world, all screens are wireframed and approved by the client prior to beginning this dev/designer workflow. This needs to be taken into account and planned for, but the real kicker is either getting the entire project team onboard from the inception of the project and keeping them there until the wireframes are all complete, which increases project costs, or having a well oiled creative group capable of making spark decisions on wireframes, decent comps that support the business need, and just enough umph to wow the customer and exploit WPF or Silverlight without forcing a design interaction. Often times, the Dev and the Interactive Designer (Integrator) are left to stumble building an app in hopes that the design assets being produced will hold true to the vision of the architecture being put in place and can be implemented. There's something to be said about measuring thrice and cutting once, but in the production world of software dev, customers rarely support the notion or even respect the ingredient of time; so we're often left stumbling through the wireframe definition phase in parallel with the early development or prototype.

Collaboration, not in the sense of a cohesive team willing to dive into the project together, or even a creative group capable of making spark decisions on UI/interactions, I’m talking about collaboration with the customer. Full committal from the Customer is paramount to success in .Net 3.0 projects, two-fold; I’ll get to that in a minute. I found this article on Gantthead last Monday to be particularly interesting: http://www.gantthead.com/content/articles/238587.cfm. It provides a motivating approach on participation levels from customers, and describes an interesting bit about how to find out why customers resist collaboration. I’ve seen many of the points described in real projects, and honestly, it’s tough to get customers to see and realize value that they bring to the table. Often times, the wrong stakeholders, or those that are too busy to participate on the project effectively, join the clan. Convincing the sponsor to place the correct, accountable bodies on the project is key, but getting those bodies to adopt collaboration is a challenge. Another dilemma I’ve found is the lack of participation during review cycles. I can see the value of dedicating more time up front to teach the stakeholders the value of collaboration as opposed to he who is made available only to answer questions as requested. This is certainly not a collaborative project as the article suggests.

Back to WPF projects – .Net 3.0’s presentation layer is abounding with possibilities. I don’t feel that a lot of customers fully understand or realize the value of collaboration on this platform. It’s a very hands-on, touch feely, truly out of the box, paradigm shift provided on UI, UX, and interactivity. Too often, we’re left to define and describe this information because 1) customers are overwhelmed by the vastness of the platform’s capabilities, 2) customers saw something they liked at an event recently and are hard pressed to get it regardless of the risks, and 3) customers simply don’t realize what a value proposition their business and data expertise bring to the project. I think more interesting UI and interactions are on the horizon when customers intend to collaborate with us and actually follow through and deliver on that while we build rich applications together.

Software development projects often get off to a good start - meetings take place with the clients, you begin gathering business requirements, you understand the technologies needed, you understand the client's vision, you've got a Technical Architect in place to lead the project's technical efforts, and you may even have a decent plan in place for the QA and Deployment phases of the project. But, has anyone begun discussions about what content is getting fed into the proposed system/solution? D-A-T-A - it's gotta be the most important, most misrepresented piece of any data centric software solution.And I don't mean the data transport layer. I'm talking about the raw data itself. What does the client intend to surface in the UI? Where does it need to be surfaced, how are the data related, and why? Is the data being generated by humans? If so, is there a solid plan in place to detect exceptions in the data that may cause major dilemmas in your application? What are the data requirements of the assets in terms of dimension, magnitude, quality, format, file size, and a slew of other attributes? Is the data feed normalized enough to provide the granularity needed in the various parts of the solution? How will the data be exposed to the application or solution? In what format can the solution ingest the data? If it's media data (better keep reading), is there infrastructure in place to properly move the data? What are the bandwidth expectations for the solution? How about the expected user population's bandwidth dealing with video, for instance? Are the data assets too large for the UI, and hence, you're robbing the UX with gobs of never surfaced pixels?

The list of questions can be mindboggling. It should be considered in the project plan.

Your visual designer has created a unique UI concept, and most importantly, it seems to fit the client's needs, but how do you promote this UI to the client? I've run into this several times since many of the common UI paradigms that folks are comfortable with are out the window...it's tough to convince and push a new concept that seems foreign to some. Be sure that you get the client on a phone call, at least, and allow plenty of time to review the concepts visually over some interactive web tool. More importantly, this UI concept design review will surface vital errors in the design. Engage the entire team and make good use of an hour slot. Don’t depart the meeting without an internal review of the outcome to assure that the design moves forward correctly and the next set of mockups are delivered quickly to avoid losing the momentum of that heated meeting. Be sure to continue iterating on them via email immediately. The PM's goal is to get locked on a design concept.

On the flip side, it’s vital to assure that the developers can pull off the design given the estimate that they provided for the project. If not, your budget is in jeopardy, assuming you're doing a fixed bid project with an estimated cost structure from the developers. Going too deep in your design, without a team lead and/or integrator validating the design along the way, is a critical error for a PM on this technology. Ideally, the visual designer should be free to explore UI, and the client should reel in the team if it’s gone too far. Just don’t bite off too much is my point. Don't forget about your QA team, too. They need to be just as engaged. It keeps the PM's job minimal here, too, since the test plan is fed from this information and the handoff is self evident.

Microsoft .Net 3.0 projects provide opportunities to build awesome UI, right? And surely you've got a developer who can construct WPF controls necessary to support the UI. So you've got a visual designer providing xaml assets to support his cool new UI concept, and your developer is quickly at work providing prototypes for the controls, and perhaps a test harness for the designers...but how does the visual designer's xaml get fully realized in the WPF app? First off, it's clear that the implementation of the UI is rarely done to the designer's full intentions. Enter the Integrator role. The Integrator understands the needs of the developer while also supporting the needs of the designer to assure that the app's UI is as compelling as it was designed, while also validating that the concepts can be realized in code from the developer. The integrator also needs to be able to implement animations and interactivity provided by the interactive designer. He speaks the language of both parties and should be a good negotiator, in my opinion. It also seems clearer these days that some face time with your visual designer and your integrator will assure that the hotness of the UI is realized - it seems less clostly to get the two of them on a box, and tweak the UI as needed. There is quite a lot of diversity in what this integrator role does, and I must say, I don't have all of the answers yet.

I know this article is about a month old, but the day it was printed, I found it very intriguing - I mean first off, let's face it...when the client requests a new feature, as a PM, your gut wants to jump on it and provide good service to your client by idenftifying if it clearly sits out of scope, if it teeders on the fence in the gray area., or if it indeed is in scope. I can honestly say that procrastinating is a good trait to use when such requests come in. Rather than jumping on the latest feature that's gotta get into the app, leave it idle for 48 hours or so. For one, what may seem simple from a dev perspective to implement, and be considered something that could be done quickly with little cost, you may be opening a can of worms by reaching out too early! Don't let the team members identify to the clients the breadth or scope of the work either - drive this yourself - set the stovetop to Simmer!

 http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=288463&pageNumber=1

 

In this blog, I plan to discuss the minutiae of my craft - managing technology projects based on the .Net 3.0 platform. I can say with certainty that early on, this platform clearly had boundaries between the developers and the designers, and it was a difficult shell game to get the right resources doing the right tasks in the right order on the right bits. Nonetheless, .Net 3.0 has come a long way since then, but trials and tribulations still exist, although somewhat different nowadays. Conversely, there are a lot of niceties to be learned, from a project management perspective, having executed many, many projects both UI intensive and services intensive.

Check back soon for some articles. I’ve got a bunch of interesting tidbits brewing in my head I’d love to share.