Concentricity – A Tool for Planning and Accomplishing Anything

-

Monday, April 14th, 2008

THE CONCEPTS

DEFINITION:

Concentricity: the quality of having the same center (as circles inside one another).

The traditional “target” image needs to be altered, however, to allow for a flexible application. The focus at any given moment will shift to wherever it’s needed, within any given aspect of a goal, as in the following diagram:

FOCUS of concentricity: to act as a tool for planning any goal of any size.

THE PATTERN

STEP 1) BRAINSTORM

Brainstorming is simply getting all ideas on paper. Not all ideas need to be GOOD. Just get them down. They can be discarded later. Brainstorming can be done as a group or individually.

Here’s an example; it’s the brainstorm that preceded the presentation of this topic.

I want to make sure that this is something that doesn’t just show what I know about the topic, but I want to make sure that this is something that is useful to everyone that comes to the training–designers, administrators, developers, and Andy. How will I do that? I will suggest some ways that might be useful to all of the demographics within the room. I have to remember to give a ten-minute summary. It needs to be something flashy and that makes the topic sound like it’s as useful as I believe it is. I have given a brief history about how this came about. I think that it may be useful to present how this is different than the Franklin-Covey approach. I have explained how this has helped me to accomplish certain things I have explained the kitchen situation as one example. I have talked about how this is useful from big situations to small situation. I have talked about how the piano students and I use it. I have talked about how it is a dynamic thing. I have talked about how this is a completely versatile thing. I have talked about how tit applies to every aspect of the organization process. I have talked about how this applies to all of the projects that we do. I have talked about how this gets clients and developers on the same page. I have talked about how the prototyping system is part of this. I have talked about how the user testing and use cases fit into this. I have gone through a project with them using the process. I have helped them to see how this is something that they could use. I have shown how this is something at so many different levels. I have shown how it will minimize backing up and having to redo things within the development phase.

STEP 2) OUTLINE

The step following the brainstorm is to refine the brainstorm into a working outline. The outline is organized with its most important ingredients first, and decreases in importance from top to bottom. There are examples of outlines at the bottom of this post with the mediaRAIN – specific examples.

STEP 3) REALIZATION

Realization is completing everything in the outline, working from specific to general. Each step that has substeps requires that the substeps be completed in order to consider the step completed. When completing an outline, work from specific back to general. In other words, realization is executed from top to bottom generally, but from bottom to top (specific to general) locally.

***THE EXAMPLE***

The following example shows how the three-step concentricity process can apply directly to a mediaRAIN project. You’ll want to skim over some of the content (such as the brainstorm) to just get the general idea of how a step may work.

COMPANY / CLIENT COMMUNICATION ENHANCEMENT

Step 1) Brainstorm

The experience that is gained as a company is only as valuable as 1) the people that have had the experience that still work for the company, and 2) those things that are written down and communicated. There are some communication issues that could so much better be worked out if clients, designers, project managers, and developers had access to 1) a central place to communicate for the projects upon which they’re working, instead of trying to communicate around each other with email, phone calls, etc., and 2) a place where things learned as a company could be shared. that way, the working outline, all ideas and concerns about it, and all communication about issues relating to it could be centralized, and everyone could have access to the information that is vital for everyone to have about the project. Since there are appropriate channels of communication and command, those need to be respected and built into the system. At the same time, everyone who is involved in the project needs to be notified when there is information from which all could benefit. It needs to be project specific when there are projects that are involved, and it needs to be company-specific when there are things that can benefit the company long-term. That includes a wiki that employees and employers could contribute to about specific activities and situations, so that if I have an idea about how to talk to clients, it can be reviewed by the person who’s in charge of the content on the wiki and reviewed by that person and then posted for everyone. Something like Google Talk could also be integrated so that those that need to could be involved in conversations about particular topics. Communication channels can/should be limited by the project manager so that clients don’t talk directly to developers when that’s not appropriate. Right now a lot of people get left out of the emails/phone calls/meetings when something gets in the way. This would be something that is less prone to that.

Step 2) Outline

The first outline clarified what the real goal was, so there was another, more specific outline, followed by this final version:

Step 3) Realization

To realize the outline, the following checklist takes the outline and turns it into a usable format, with assignable tasks, people responsible for them, and a timeline. The timeline may seem random, but is carefully planned according to the outline; subtasks are completed before larger tasks are counted as completed, so larger tasks have later deadlines than their “children.” All phases that can happen at the same time are planned to do so, since the framework has been organized from the beginning.

Of course, the three-step process of concentricity is used at every level during every phase of development, with more brainstorms, outlines, and checklists

– Bryan Elkins

(more…)

Process

-

Thursday, September 27th, 2007

I hope the main things we took away from the process training is this:

Prototyping is the Anti-Waterfall

Doing development and design iteratively has distinct advantages over the traditional waterfall approach. It creates a high-quality plan while keeping the client heavily involved and able to make needed changes. I hope that this iterative approach can be used more and more as we learn about it.

Progressive Enhancement

If we can get to the point where we’re think about what needs to be there rather than how it should look (or act), I think we’re winning the battle. For HTML-based applications, its content -> structure/markup -> presentation -> behavior. For some of our more interactive Flash applications, we need to think about what functions are needed, then organize them and give them context, then decide how they should look.

For HTMLers, I’d ask they maintain separation between these layers (no inline styles or JS, good semantic markup). Font tags and tables can sometimes be the result of not progressively enhancing something. Any of you Flash guys have some best-practices on how layering can work well in Flash/Flex applications?

The Process is not a One Man Show

This has two main facets: first of all, I don’t want to become the process-police. I want as much feedback as I can on how things should work so we can test things out and continually become better at we do. Please check out the (temporary) Process Wiki and send me a note. Thanks to those who have reviewed things thus far. This has got to be a community effort, or it won’t work.

Secondly, I hope we can start to involve the many roles we have here at mediaRAIN in more parts of the process. If we have a designer, developer, and business manager providing some input (however small) at every stage in the process, none of our applications will ugly, unstable, or unprofitable. The more we can break down any walls between these groups, the better.

That said, here’s the Process wiki page. Those of you who have found my Process easter egg have been rewarded. Best of luck to the rest of you.

Contract Killers

-

Tuesday, September 18th, 2007

I just read a great article by Andy Budd that talks about an alternative approach to bidding out projects. called “Target-Scope.” It looks like a great idea (it might be akin to what the ZenPrint estimates were like). What do you think about an approach like this?

http://www.digital-web.com/articles/contract_killers/ 

And how do we approach clients so that the discovery phase is a win for both of us?

Tips for project managers on courting clients

-

Friday, August 24th, 2007

Because Rain handles a number of large projects each year, we benefit from a wide range of project management experiences. Here are some recent lessons I wanted to formulate into a post.  This content is intended for other Project Managers at interactive agencies.

Courting defined:

The courting stage is when you are going back and forth with the client talking about price/scope/timeline before you have any contract signed.  At this point you and they are figuring out if it is going to be a mutually beneficial endeavor.

Ownership/Revenue Sharing with Clients:

Being a service company means that we make our money mostly on services we provide for our clients.  There are a few products that we have and can sell, but it isn’t our core business.  What that translates to is that it does not make a lot of sense for us to enter into ownership/revenue sharing agreements as a payment model.  Stay away from these types of deals.  If they don’t have money to pay, it’s just going to hurt you in the end.

Setting Precedence:

Show clients up front how you like to work.  Set the rules for communication in the first few meetings. Make sure the client knows how to use the channels of communication in your organization appropriately, as late-night calls and direct developer contact can cause problems.

Warning signs:

Look out for clients who are overly nervous, micromanagers, prone to overreaction, or who seem overbearingly aggressive.  If they display these attributes add additional time into the bid to deal with wrestling over price/scope/timeline.  Better yet, go hourly if possible.  These clients can be great for your business, just keep in mind they may have a tendency to change direction during development.

WBS:

The Work Breakdown Structure (WBS) is essential in estimating large projects.  It is a great way to visually represent to the client how the application is balanced and where the costs come from.  Make sure and create one of these in the courting phase to give an initial cost estimate, then again after the prototype phase.

There are a few different software options available for creating the WBS. If you are on a mac, I recommend Omniplan; PC, then MS Project.

Here is an example image of a WBS.

 Responsibility for Services:

As a Flex shop, we’re often asked to do only the front end work, leaving the server-side services up to the client. When you’re not in full control of this critical part of the project, plan ahead by charging hourly or padding the estimates for the project generously. Moving targets and late deliveries by the client can cause problems.

In conclusion, courting clients is one of the most important phases of a project, and hopefully following these suggestions will help you and the client get the project started off on the right foot.