Our move reminds me of every single website launch at Matrix Group. When a Project Manager reports that he or she will be done with a project when it launches, I warn that there could be weeks of tweaks and that we should just expect it. Here’s why:

Sometime, you just don’t don’t know where to put something until you’ve lived with it a while. I wish I could say that our information architecture process is perfect and we account for every piece of content, but it’s not and we don’t. Clients often have to live with a site for a few days or weeks before they figure out where everything should go. In the meantime, content doesn’t go up or it gets stored under some generic navigation called Resources. I feel like Resources is like our garage; there’s a lot of great stuff in there but it’s hard to find what you’re looking for and you know you need a better organization system.

The little tweaks can make all the difference in the world. The new master bathroom in our house is wonderful but it had a few problems. You had to walk inside to reach the light switch and the towel bar was several feet away from the shower. We were unhappy from the beginning but we didn’t know what we wanted or how to fix the problem. Then one day, my husband came home with a wireless outlet that he attached to the wall. Voila! We can now turn on the light before entering the bathroom! And a hook added to the wall just outside the shower solved the towel problem. Same with a website. We often need a few days or weeks of real users road testing the site before we can make the slight improvements to the flows and paths that make the site really great. For one client, we added a Google map link to a calendar application; it was amazing how much happiness 2 lines of code created.

You can’t finish decorating right away. Our new house is laid out in a very similar manner to the old house but nearly everything had to be re-arranged. Bookshelves got moved around the house, we re-arranged the closets, and the living room is completely different, even though the dimensions are the same and we didn’t buy new furniture. With website redesigns, small changes to the navigation sometimes means a total rework of the content and CMS. And clients often can’t conceive of how to “dress up” pages with images and formatting until they are live.

You’ll get more done if you throw a party. My mom always says that if you want your house to look good, throw a party. You’ll get the boxes unpacked, the pictures hung and the furniture arranged – just in time. When a client picks the launch date for their website, we ask if they will be unveiling the site at a conference or event. I love having a deadline tied to a conference because conferences don’t move, which means everyone hustle to get things done and it’s amazing how much content gets written right before the event and launch.

Anticipate the tweaks. At Matrix Group, we know that it takes time for clients to get comfortable with the new site, use its new functions and figure out what’s working and not working. Leslie Blum from Carolinas AGC calls them “iron outs” and she’s right on. It generally takes between 2-4 weeks to get the help text just right, all the new content loaded, and the integration use cases all worked out. So rather than fight the tweaks, we anticipate them and plan for them in our schedule. I will caution, however, that tweaking past 30 days can get counter-productive. You run the risk of the team losing steam and experiencing launch fatigue.

In the last 30 days, we’ve launched new sites for the Ironworkers, the American Society of Addiction Medicine and the Washington Building Congress. Although the sites look great, we’re still tweaking. :-)

© 2007 USPS. All Rights Reserved.

In honor of May 4, a sacred day among Star Wars fans (because George Lucas released all of the Star War movies on May 4th), I’m blogging about my Rule #1: Do or do not. There is no try.

Clearly, I did not make up this rule. It’s Yoda’s rule. But it’s a damn good rule, especially in business.

Here’s what I know: Clients don’t come to us so we can TRY to develop the complicated web application they need. They need us to do it. And they need to know that we will be successful and the end result will be close to what they envisioned.

I learned a long time ago that when assigning tasks that must get done, I don’t ask staff if they can do it. I provide background, then ask what they need to get the project done, what obstacles are in their way, and how I can support them. And when I get, “I’ll try,” I remind them that “I’ll try” is not a commitment and it’s not a promise, it’s a half-hearted “maybe” or a definite “no.”

Now, if we’re brainstorming, assessing options or exploring whether or not we can accomplish something, then I ask if we (Matrix Group) can do it. And it’s perfectly legit to say, “I’ll try.”

So what happens if someone (me included) doesn’t know exactly how to get the required task accomplished and can’t quite commit to it just yet? In that case, I ask people to give me a plan that details what they are going to do so they will know and can commit to a timeline and budget.

In Star Wars Episode V: The Empire Strikes Back, Yoda lifts Luke’s starfighter from the swamp. An incredulous Luke says, “I don’t believe it.” To which Yoda retorts, “that is why you fail.” Like Yoda, my best developers, front-end developers, designers, admins, project managers (yada, yada) believe they can accomplish ridiculously hard tasks under ridiculous deadlines. That is why they succeed.

We called Boombah to complain that we ordered shirts with a sublimation process, which, incidentally, is what our e-mail receipt says. The Boombah sales rep said something to the effect of “the sublimation process is only available for the white and gray shirts. Our receipts say sublimation as part of the template, but it’s wrong. Our website is very clear that you can’t get sublimation with the black shirts.” (Don’t get me started on what happened when I asked to speak with a manager or the owner. It was not good.)

Okay, forget that the invoice says sublimation. Boombah violated what I affectionately refer to as JP Rule #3: Never let your client make a mistake. In my mind, if we had called asking for black shirts with logos, the rep should have made sure we were crystal clear on the concept that sublimation, which is the nicer printing method, is NOT available for black shirts. Knowing that fusion on black makes for a crappy shirt, the rep should have at least tried to prevent us from making that mistake. Yes, we ultimately placed the order and we take responsibility. We paid for the shirts and promptly ordered a batch from another company.

Whether it’s shirts or websites, clients rely on their service providers for expertise and recommendations. It’s up to us to educate our clients, make sure they understand the options, make recommendations, and warn them if we think they’re about to make a mistake. Yes, clients ultimately need to make their own decisions and they are big boys and girls, but if we hold technical knowledge they don’t, shouldn’t we at least make sure they are aware of the impact of their choices?

Case in point. A new client was implementing MatrixMaxx, our association management software. Our main contact told us that the association didn’t need any company demographics as part of the setup. We questioned this decision several times and he maintained that no, the organization did not need to collect company data outside of contact information. Knowing this is wrong and a waste of an opportunity to gather member data, we took the issue to the VP. Without making it seem like we were going over the manager’s head, we let the VP know that we thought the organization could benefit from collecting additional data as part of the member profile and membership application. We even suggested a package of fields. Sure enough, the VP, who has a bigger picture view, agreed on the demographics. We *could* have dropped the issue after confirming with the manager. We would have had tons of documentation showing that the client rejected the additional fields so that if the client came back to us a year later, we’d be perfectly justified in charging extra money for a change order. But that behavior would have violated Rule #3.

We try to live Rule #3 and we don’t always succeed. There isn’t always clarity about what’s absolutely right and what’s absolutely wrong. We don’t always realize a decision will be the wrong one in the long run. And clients don’t always agree with us. BUT, I believe that we have an obligation to our clients to at least give it the old college try and help them not make mistakes.

How about you? Got any stories of a vendor who let you make a mistake or saved you from making a bad decision?

P.S. I have a total of 23 rules. I’ll try to blog about them all in the future. If you’d like a copy of the list, let me know.

MatrixMaxx is Matrix Group’s Web-based association management software (AMS) that is used by dozens of trade associations and professional societies to manage their membership applications and renewals, meeting registrations, committee rosters, tradeshows, sponsorships, foundation fundraising, e-mail lists, and publication sales.

Beer and cream cheese is the software development methodology we came up with after exploring several agile methodologies, including SCRUM.  While there are many flavors of agile development methods, most are characterized by:

• Breaking big projects into smaller tasks that can be accomplished in hours or days, never weeks or months.
• New versions of the software are released in short timeframes, called timeboxes or sprints.  Sprints can last 1 day to 30 days.
• The goal of each sprint is to produce a working product that the client can use immediately, rather than having to wait months or years for a release, bug fix or new functionality.
• Each team has a customer representative who represents the client perspective and makes him/herself available to team members.  In the case of SCRUM, there are 3 roles: the ScrumMaster (who serves as the project manager); the Product Owner (who represents the stakeholders/lients); the Team (the staff who do the development work).

We call our methodology beer and cream cheese because about 18 months ago, Tanya, the MatrixMaxx Director, posted to one of the SCRUM message boards, asking if anyone had experience with having the same person be the ScrumMaster AND the Product Owner.  One ScrumMaster sarcastically remarked, “You CAN do it, but that would be like combining beer and cream cheese.”

Fast forward one year.  The MatrixMaxx team is still using beer and cream cheese, but our process has changed, and for the better.

• Where Tanya used to play the role of Product Owner and ScrumMaster, she is now the Product Owner.  Geoff is our Brewmaster.  As a result, Tanya can focus on the product road map and client requirements.
• Our sprints are now 15 days long.  Major product releases are quarterly, but we put out small enhancements, especially custom enhancements for clients, twice a month.  Clients love this!
• Although we still primarily use our intranet to manage tasks and requirements, there is a whiteboard in the MatrixMaxx team area that lists tasks that have been designated for the next release/sprint.
• We’re doing a better job of tracking projects and elements that tend to go over budget.

We plan to refine our beer and cream cheese process even more over the next year by:

• Going back to shorter, daily check-ins, which have turned into lengthy discussions about tasks and requirements.  We realize that the entire team does NOT need to be part of all in-depth discussions.
• Giving each team member one long item and one short item per day to encourage maximum productivity from all team members and help us manage the backlog of small items.
• Making a renewed commitment to identifying and analyzing tasks that tend to make us fall behind or go over budget.

BTW, we still hold beer and cream cheese parties where staff bring in baked goods made with beer and cream cheese.  My favorite this year was the dark chocolate cupcakes made with beer and topped with cream cheese frosting. Yum!

How about you?  What software development methodology does your company use?  Are you an agile shop?  What’s working for you?  And how did you select the methodology that you are using?

I’m having a baby tomorrow

The answer to the first question (how much time are you taking off?) is not clear cut.  When you’re a small business owner, you can’t exactly just disappear for a few months. When you’re the owner, the business is your baby, it’s part of your life and your identity.  That said, I’m giving myself the flexibility to work as much or as little as I want, come in when I feel I need to, and decide when I’m ready to come back to the office full-time.

The answer to the second question (how will the office survive without you?) is “Just fine, thank you very much.”  In fact, just like the last time I was out with my first son, I expect the office to thrive. Here’s what I’ve done to prepare myself and the office for my absence:

What Is It That Only I Do, or Can Do, At the Office?

When I first announced to my management team that I was going to have a baby, the questions I asked of myself, the Directors and Project Managers was: “What is it that I do, that only I can do, that you rely on me to do?”  Then we got to work documenting the list and figuring out a plan for getting those tasks done in my absence.

For example, I review the monthly billing reports after the Project Managers (PMs) have reviewed them to double check that we are properly marking work as billable or unbillable.  Over a period of a couple of weeks, I went over dozens of reports with the PMs, discussed why I question certain items and provided suggestions for how to handle ambiguous items and make sure clients are never surprised by their invoices.  The Director of Client Services will also now review invoices in my absence.

Documenting What’s in JP’s Brain

When you’ve been in the Web business for as long as I have (since 1994 but please don’t try to calculate my age!) and when you’re responsible for landing a lot of the company’s business, you just accumulate a lot of knowledge about clients, process, and projects. Even though I use our intranet religiously to document all of my communications with clients and prospects, there’s just a lot of knowledge that I carry around in my brain.

So over the past few months, I worked with my team to document the strategies, best practices, and potential land mines I’ve encountered while working on myriad projects. I paid special attention to the project components that I tend to spearhead, including Goals and Personas, Content Strategy, Integration with a Back Office CRM (customer relationship management system) or AMS (association management system), CMS (content management system) reviews, and Social Media.  These are now called PM Guides and they live in our wiki. All staff are encouraged to modify them as needed.  The guides are reviewed before the start of each project, and the PMs are loving the sample agendas and notes for running meetings.

Letting Staff Shine

When I took time off with my first son, a great thing happened: the vast majority of my staff rose to the occasion, took on more responsibility and did a great job. Some of them said they wanted to do a great job so that I could be at home with CJ and rest easy knowing that the office was in great shape.  Others saw the time as a terrific opportunity to show what superstars they are.  Still others ran with projects, figuring they should act first, apologize later.  The results were great.

This time around, I’m trusting that the recruiting, training, practices, guides and team process that we have in place will ensure that my stellar staff can do what they need to do, not encounter bottlenecks while I’m out, and do a great job for clients.

Getting Rid of Overhang

Once we all realized I would be out,my team and I identified tasks and initiatives that had been hanging out for a while and didn’t have any movement. We either abandoned them, moved the deadline or completed them.  For example, we got cracking on our mobile strategy, updated the Meet Your Team page on our client extranet, set-up our new data center in Chicago, and moved the deadline for redesigning our demo site.

Protocol for Contacting JP Re: Urgent Items

No matter how much I plan, I know the office is going to need me for certain things, like complex contract negotiations and developing a strategy for responding to big, hairy RFPs (requests for proposals).  So I’ve alerted the admin team that after a few weeks, I will call once a day; whoever needs to speak with me needs to be ready with their list.  And to help me wade through the mountains of e-mail that will collect in my inbox, we selected a codeword that staff will enter in the subject line to indicate that a certain message is urgent and needs my attention. This way, if all I have is 10 minutes to check e-mail on any given day, I can filter by the code word and see the most important and urgent messages of the day.  No, I’m not divulging the code word here, but suffice it to say that it involves Star Wars.

There Will Be Hiccups

Are the plan and system perfect?  Absolutely not. In the end, I will rely on my sterling staff to do a great job while I’m out, which I know they will do.  I’ve warned everyone that there will be hiccups, errors and crises, but if they keep the interests of their clients and staff in mind, overcommunicate, and stay on top of deadlines, they’ll be great.

How about you?  How has your company prepared for an extended absence of your CEO or any key staff member for that matter?  What worked?  What did you learn?  Please share!

Now, I’m off to have some spicy food and go for a brisk walk.  I have a baby to birth!

While I’m sure most of my staff would have loved a snow day or two, as a small business owner, I know that when my staff isn’t working, we’re not generating billable time, which means a bad month in revenues, or worse.  So, since Friday, I’ve kept the Matrix Group office officially open but let everyone work from home. Here’s why:

• Most staff appreciated not having to battle the bad roads to keep working and avoid taking vacation days.
• Although most of our clients are in the DC area, we have clients all over the country; the latter expect us to be open.
• It’s precisely when our clients are not able to serve their customers and members physically that they rely on their Web sites to be open for business virtually.
• Letting staff work from home let us put our pandemic/DR plans to the test.

The results have been mostly good. With the exception of staff who lost power at home, everyone scheduled to work has been able to work.  Here’s what helped:

• The Matrix Group network administrators worked hard to give the entire staff VPN access to their desktops and the network.  In fact, until today, the network admins somehow made it to the office every day.
• We established a protocol for keeping in touch via Instant Messenger (IM).  We each announced to the entire staff when we started work each day, we stayed on IM, and we kept our statuses current to let other staff know if we were AFK (away from keyboard) for lunch, shoveling, etc.
• We used a free conference call service to conduct conference calls between staff and with clients.
• We use Webex to review documents and pages together, as well as Skype and Yahoo!Messenger to do group chats.
• Staff kept in close touch with their managers to discuss their plans, priorities and workload.

On Tuesday afternoon, I polled the entire staff and asked for their feedback re: working from home.  I learned some surprising things:

• Nearly everyone complained about latency on the VPN.  It seems we saturated our two T1 lines with all the remote access connections.
• Many staff members have cell phones only and they reported difficulties doing lengthy conference calls on their cell phones or were worried about running out of minutes.
• Most people missed the energy of the office, being able to conduct business face to face, and the convenience of nice computers, multiple monitors and fast access to the Internet.
• Several people complained about missing their chairs!
• Many staff members reported greater access to their managers (although I suspect it’s because managers were less likely to be on the phone with so many clients not working!).
• By Day 3, many staff were experiencing cabin fever in a big way.
• Those of us who are parents tended to take longer breaks AFK to take care of the kids.

All in all, I’m pleased with the Work From Home experiment.  If we do have a pandemic flu, we’ll be ready.  I’m grateful to have such a hard-working and committed staff; I feel like they’ve stayed in good spirits and have been very productive.  As for me, I miss the office, I miss my staff, I miss my chair, I miss my quiet office and I’m ready for my five-year old to be back in school!

How about you?  Did your company stay open or close during Snowcalypse?  How are you dealing with all this craziness?

Matrix Group:

• Included a user-friendly navigation that lets visitors know about Campbell Wealth Management’s financial services.
• Added interactive videos that provide information on financial strategies  and best practices to building, managing and protecting financial assets.
• Valuable tools and forms to help visitors with their financial planning, including  financial calculators to assess their current performances and outlook.
• Incorporated information on Campbell and his team, highlighting their accolades and expertise in the financial planning sector.
• Collaborated with Campbell Wealth to ensure that the site complied with regulatory standards.

Visit the New Campbell Wealth Management Web site!

This afternoon, the MatrixMaxx team at Matrix Group held a Town Hall meeting with clients to get feedback on about a half dozen features slated to go into the 10.1 version

Instead, we decided to crowdsource the specifications.  Crowdsource?  What does this mean?  Wikipedia defines “crowdsourcing” as the “act of taking tasks traditionally performed by an employee or contractor, and outsourcing them to a group of people or community, through an “open call” to a large group of people (a crowd) and asking for contributions.”  Wikipedia also uses this definition: “the trend of leveraging the mass collaboration enabled by Web 2.0 technologies to achieve business goals.”

In the past, Tanya (the Director of MatrixMaxx) and I would sit down, discuss requirements, maybe make a few calls, and then decide on the specifications for each release.  This time around, we decided to get immediate feedback from as big a group of clients as possible to validate our ideas and generate new ones.

The Mechanics of the Town Hall Meeting

• We sent an e-mail invitation to all MatrixMaxx clients, inviting them to an hour-long, online Town Hall meeting.  The e-mail provided details on the half dozen topics under consideration, with a general discussion of the options available.
• Clients were invited to provide feedback in real-time during the meeting, before the meeting via phone and email, and after the meeting via phone and e-mail.
• About 60% of the clients registered at least one person to the Town Hall meeting, which was conducted via conference call and Webex.
• Tanya ran the meeting, leading the discussion and taking notes, which were shared out via Webex to all participants.

Immediate Benefits of our Crowdsourcing Experiment

I don’t think the meeting could have gone any better.  Even I was surprised at the level of engagement from clients, as well as the thoughtful feedback on our proposed changes.  Here’s what we learned:

• A bunch of brains are definitely better than 1, 2 or 3. In one hour, we explored topics and prevented duh! moments in February.  For example, we proposed making the CID (the security code on credit cards) required on all meeting registration forms, but several clients correctly pointed out that they have already sent out paper forms for many meetings. If we require CID and they get back a bunch of reg forms back without the security code, they’ll have to call members and cause a lot of extra work. So, could we require the CID on the WWW side but not the intranet side? Honestly, we had never considered splitting the requirement between WWW and intranet.  What a great idea!
• The Town Hall meeting got the attention of clients we rarely hear from, despite regular outreach. When we have little contract with specific clients, that’s a red flag because we don’t learn about their issues and problems, which means we don’t have the opportunity to fix them.  The meeting was a great way to re-connect with clients and show them we want to hear from them!
• Clients liked hearing other client perspectives. In the past, when we decided to implement a feature one way, we made some clients happy and others unhappy.  Today, clients didn’t all agree, but they seemed to appreciate hearing about why another organization didn’t share their point of view.

The biggest benefit to the software team?  We got resolution on a bunch of requirements and the developers can plow ahead with their coding.  We are definitely going to do this again in the future, maybe even do a Town Hall meeting prior to the planning meeting for each release.

How about you?  What do you think of our experiment?  Have you participated in a crowdsourced event or project before?  If you participated in the Town Hall meeting, what did you think?

After each Web site launch, I ask the Project Manager in charge what’s left to do.

Project Overhang is what we call tasks that are left over from a project. The project, site or application can be up, tested and launched, but there are tweaks we didn’t complete, post-launch fixes or small change orders.  Often, Project Overhang does not generate additional revenue and the items are so small that they can slip off our radar if we’re not careful.  Project Overhang is much less likely to happen on a client account because those projects are external, revenue-generating and discussed during post launch check-ins.  But Project Overhang on internal projects can linger for years!  I once had a to do item to update a new staff orientation guide that didn’t get done for two years!

Which is why I’m trying hard to make sure we have no overhang from our recent office move.  We moved 2 1/2 weeks ago, we’re up, we’re running and nearly every box is unpacked.  Notice I said “nearly” every box.  It’s the last few boxes that take forever to unpack.  I have two boxes at home from a move back in 2001 that are still waiting to be unpacked.  So back at the office, we are continuing our SCRUM process to get all move-related items done by the end of the month.  In fact, by Friday, I plan to have my office “done,” all prints hung on the walls, and all boxes in the kitchen and supply room put away.  The remaining Project Overhang will be to unpack the CTO’s office, but that will be the topic of another blog post. :-)

My tips for dealing with Project Overhang are:

• Acknowledge and catalog the overhang so that it stays on everyone’ s radar.
• Set-up designated times to deal with overhang.
• Give prizes to people who clear out the most overhang. I like gift cards, extra time off, iTunes cards.
• As with clothes you haven’t worn in over a year, ask yourself (or your boss, co-worker or client) if a task is still needed. If the answer is no, delete that task forever from your to do list

How about you?  Do you have overhang at work or at home?  What’s your most ridiculous overhang item?  What are you doing to clear out the overhang?

Here is our Office Move To Do List at the start of the day on Saturday.

• Jaime, the Director of Administration, was the SCRUM Master. She was in charge of managing tasks, answering questions, and making sure people didn’t have any impediments to getting a task done.
• I was the Product Owner since I am ultimately responsible for the office.  I was consulted on priorities and tasks that affected the entire office, like the kitchen set-up, where to put up posters, etc.
• We set-up a SCRUM board in the reception area. As staff arrived, they were told to: go get a doughnut, set-up your work area, then grab as many tasks as you can to help complete the move.
• The SCRUM board was covered with tasks written on Post-It Notes.  Jaime and I populated the initial tasks, but we invited other staff to suggest more tasks to the SCRUM Master.
• When a staff person completed a task, they initialed it, then put it on the DONE board.
• Since Jaime and I were the leaders of the project, we didn’t have as much time to unpack our own offices, so we asked for help by putting up tasks on the board.  We got a lot of help as a result!
• We didn’t have people milling about, wondering how they could help, and feeling frustrated for lack of direction.

Everyone who came in on Sunday helped.  Some people completed a lot of tasks, while others completed just one.  What mattered was that so many tasks that normally get delegated to the admins got done.  The Director of Client Services wiped all the white boards clean then distributed them.  A senior Developer wiped down the credenzas in the conference room.  A Project Manager put up the bulletin board in the kitchen.  Three staff members unpacked the kitchen.

Here is To Do List next to our Done List by Sunday evening.
Nearly all remaining tasks were done by Wednesday afternoon.

The results were unbelievable. By Sunday evening:

• Pretty much everyone had their workstations working.
• The dev sites, network shares and printers were up and running and tested.
• The kitchen was unpacked and the coffee maker functioning.
• The new VOIP (voice over IP) phones and Internet access were working and tested.  (It’s taking a few days to get used to the new phones, I think transferring a call is taking too long, and the hold music needs to be updated — but we’re getting there!)

The best part?  Instead of the move being a drag, we had a party! (Doughnuts, pizza, music and beer helped!)  And I didn’t hear complaints about how things weren’t working as planned because everyone helped and knew how hard the admins and net admins had been working to ensure a smooth move!

We’re now trying to figure out how to use a similar process for other, non-technical projects at Matrix Group.  How about you?  How have you used SCRUM in unique ways and situations to get a project done and done well?

User Experience

• Our construction project began with our Architect visiting our existing space, interviewing staff, and learning how people work together and on their own. This is akin to the user experience part of all of our Web projects where we look at analytics, interview staff and users, and create personas to represent key target audiences.
• The space plan and architectural drawings are akin to navigation and wireframes. In our case, our Architect conducted a test fit to make sure the space would fit our general needs, then created a plan that indicated where we would have offices and where we would have open space.
• Then came design. When designing a Web site, we create multiple designs over multiple rounds for the home page, sub-pages, content pages, print style sheet, etc.  For the office, we picked carpet, colors, office furniture system, lighting, and chairs.

Implementation and Budget

• Just like any Web project, our buildout and move had a budget and we worked with our vendors to get what we needed, and a lot of what we wanted, within our budget. For example, we invested in a mid-grade furniture system for the staff in the open areas, and we got good chairs for everyone, but we’re waiting until next year to get new desks for the managers and new chairs for the conference rooms.  We also didn’t request a lot of fancy finishes on the walls.
• I made sure that we spent a lot of time on the space plan and drawings, but once they were finalized, we were careful not to change our minds, undo our careful planning, or jeopardize our timeline and budget. Matrix Group ended up with a total of 2 change orders totaling about $3,000, which I’m told is nearly unheard of in construction projects.
• For every change order or unexpected delay, we always asked the question, “what does this do to our budget and timeline?” I didn’t want to assume anything because we have a hard August 1 move date.  Nothing could be allowed to derail our schedule.

Project Management

• As with good Web design and development projects, excellent project management is key to success. I have to give our GC (Spectrum Inc, GC), the sub-contractors, our Architect (Planit Design), the furniture dealer (Office Images) the landlord, and the building management (Konterra Realty) a lot of credit.  Our weekly meetings, led by Tommy of Spectrum, were efficient and we were able to head off a couple of near disasters because everyone was engaged.
• Although my participation was not required and I know that our Architect would have represented our interests well, I attended nearly every weekly check-in meeting because I’m convinced that senior staff involvement make projects move more quickly.  As a result, decisions got made fast, and there were no surprises on our part.

As of today, July 21, it looks like we’re on track to move August 1.  The buildout is done, the final inspection is tomorrow (knock on wood), the phone and security systems will be installed this week, and the movers are scheduled and confirmed (including a special mover for the pool table!).  Now we just need to finish packing, but that’s what interns are for. :-)

I learned a lot from this buildout and I’m glad that we were able to take lessons learned from managing Web projects for ten years and apply them to what has turned out to be a relatively pain-free buildout and move.  If you’d like to see photos of the new office, including photos of the demolition and buildout, check out the Matrix Group Flickr feed.

How about you?  Have you lived through an office buildout or home remodel?  What lessons did you learn?  Any disasters or tips you care to share?

As a business owner, I get to be manager of staff and projects AND client to our many vendors.  As the chief salesperson for the company, I interact the most with customers and users.  As a liberal arts person turned techie, I know enough to be dangerous, but I can’t write a line of CSS to save my life.  All of this means that I can more easily see a situation from a client’s perspective.   Here’s what I’ve learned over the years about clients:

• Clients are busy, the Web site is usually just a small fraction of their job, they don’t spend all day thinking about the Web site, and there’s a whole lot of  stuff going on that they don’t know and don’t care to know. We can never assume clients know that a new version of Internet Explorer is coming out and it’s going to be more standards-compliant, that title tags should not be more than 64 characters or Google will ignore them, and that a print style sheet is different from a printer-friendly page.

• Most clients are non-techies who need a technical solution. They seek a solution and a result.  We need to give them context for our solution, and enough detail so that they can make an informed solution, but not so much that they get overwhelmed.  We also need to communicate concepts using terms they understand.  For example, when a Web design has been approved and we have to now slice the design, I liken it to going to blueline.  Clients who have ever had anything printed are familiar with blueline; it’s close to a final proof and changes cost time and money.

• At any given moment, clients are cold on a project, which means they don’t remember every last detail of the specifications, prototypes or testing notes.  So again, we need to provide context, we need to bring clients up to speed quickly, and we need to let them know early what we need from them.

• When a site or application is turned over to the client, there better not be any obvious bugs; otherwise, we are wasting their time.  Nothing makes a client go nuts faster than an error message within the first few screens of testing.

• When providing an update, we can’t just report on what we’ve done.  We need to provide the big picture: what we’ve done, what’s not done, what’s next, what we need from them, immediate next steps, and ultimate deadline or launch date.

• Should does not belong in our vocabulary. Should makes me crazy.  It either does or does not.  If you don’t know, don’t say it should.

For all you clients out there, what else do you wish your Project Manager and team members knew about you and your perspective?  What behaviors make you nuts?  What actions make you love your team?