Back to Home

Archive for the 'Project Management' Category

The importance of specs

Monday, May 7th, 2007

I’ve recently finished reading a book called Joel on Software, by Joel Spolsky. Despite the title, the book is not about hardcore software coding. In fact, it doesn’t teach people very much about code. Rather, Joel talks extensively about managing a software project, and the lessons learned from this book can be applied to any kind of project, not just software.

One of the most valuable things I’ve learned is the importance of specs. As a college student I never wrote any specs, at least not on paper. I would “figure it out” all in my head, and start to code like a little tiger in the wind for a few hours, until I realized that this Airplane class I had so thoroughly designed is actually missing a few key components. Now I have to stop and modify it before I can go on, and because I modified the Airplane class, now I have to modify the Flight class and the FlightSchedule class. Great. That only took about 3 hours.

Here’s what Joel has to say about NOT writing specs:

Why won’t people write specs? People claim that it’s because they’re saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to “wing it.” Programmers and software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.

…and here’s what he has to say about writing specs:

The most important function of a spec is to design the program. Even if you are working on code all by yourself, and you write a spec solely for your own benefit, the act of writing the spec — describing how the program works in minute detail — will force you to actually design the program.

Since I’ve joined IBG I have learned that specs are invaluable. Knowing what you’re going to write before you write it is 3/4 of the battle, and it will cut down your production time, as well as bugs.

So from now on, whenever you have a project, be it software, hardware, or anything else, write specs first. KNOW what you have to do before you do it.

For more info on what a spec is and how to write a spec, go on to Joel’s article.

Kevin Widjaja,

Posted in General, Project Management, Technology

Measuring Up

Monday, April 23rd, 2007

Since my very first interview with Inertia Beverage Group, I understood that decision-making here is based on some very simple yet powerful principles: Will it make our clients money? Will it save them time?

Of course saving time also saves money, I’m mostly talking about creating efficiencies. This can lead to basic cost-savings, room for new or expanded projects, increased creativity, peace of mind, or however else the client wishes to capitalize on streamlined processes. Many forms of measurement are possible.

Certainly other factors come into play as we make our plans, yet those two questions arise again and again. Most prominently, when evaluating enhancements for our software upgrades, those are the primary considerations. We are currently developing our next release, largely made up of enhancement requests gathered from clients directly or by way of roundtable discussions, our support team or account managers.

The following chart illustrates how the dozens of items that made it into the upgrade fall into the 2 significant categories, plus some administrative tasks:

Functionality of Release

I’ve found it extremely helpful to have a few significant principles to measure against, at work and at home. For us at IBG in pursuit of our mission to create powerful and effective customer-centric software, we’ve chosen our business values. What are yours?

Natalie Douvos, Sr. Director, Product Management

Posted in General, Project Management

Partnership and Appreciation

Monday, March 19th, 2007

At IBG we use the word ‘partnership’ frequently. The most obvious occurrence of the word comes from our business development team which has a host of partnerships in place or in the works in an effort to bring more opportunities for our clients to increase their direct sales channel.

A more unique application of the word comes when we refer to our winery partners. We talk about our clients in such a way since we do consider our relationship to be a partnership in selling direct and in building and enhancing our own offering.

I recently got to see this dynamic at work with some terrific results. Michael Coffey, one of our Account Managers, hosted a wine club symposium. He invited several of our wine club clients from different types of wineries to get together and talk about the challenges of running their clubs and how our tools help, as well as where they can be improved. Ideas were shared and we gained invaluable insights which will inform our next significant software upgrade.

Additionally, as one particular idea was tossed out and discussed during the session, those of us participating from IBG all took note and immediately determined that we wanted to address the enhancement sooner rather than later. Our technical team worked hard to sneak in the item into the release that we had coming out in just a few days. We hope that the feature makes the next club runs for many of our winery partners just a little bit smoother.

I want to thank those who attended and generously gave their time and shared their experiences in the spirit of cooperation and true partnership: Ed Gomez from Russian Hill, Emily Barouch at Titus Vineyards, Anne Matson from Vino Con Brio, and Tristan Fairbanks of Bourassa Vineyards.

Also, my thanks go out to the many clients who were unable to join us but who took the time to send in their thoughts and requests ahead of time. I appreciate all our partners’ on-going participation and sense of ownership of what we are creating together. Please keep the ideas coming!

Natalie Douvos, Sr. Director, Product Management

Posted in General, Project Management

What to do when you don’t have the resources?

Wednesday, February 28th, 2007

Whether personal or professional, not having the resources to do what you “need” to do is really not much fun.  It constrains you, it weakens you, and it frustrates you to no end.  Despite all of this, do not let it paralyze you. Get creative, get strategic, and you may find that your plans will change between now and when you have the resources available.  I’ve certainly experienced this phenomenon at IBG.

Under our Business Development Programs, we strive to provide our client’s with opportunities to increase online traffic, for greater sales conversion, and most importantly, to access new customers.  In order to bring a wide array of opportunities to our clients, I need some things to make these programs more efficient. 

I need widgets; I need tools; and I need technology to automate the execution of our business development programs.  For months now I have had a laundry list of what I need. What I need is relatively modest; it is justified; it is definitely needed, but it isn’t at the top of the list just yet.  Why?  Well the truth is… Paul Mabray (my CEO) is mean.  Kidding, of course. Really, the truth is that every company prioritizes needs in the context of resources available and you move from there. Enhancing our core platform has taken precedence, naturally.

In light of limited resources in the short term, we decided to go ahead and implement a handful of programs in a manual fashion until we can automate.  Despite the labor involved, we actually learned a great deal from our manual “tests” and have learned that our programs and technical needs should change.

Some lessons:

1- Through one marketing partner, we learned that there is an exponential relationship between the number of states a winery ships to and the success of an email campaign. And now, we know that we need a widget to pre-qualify clients based on states for this particular program.

2- Through a second program, we learned that discounts on wine are good but free shipping is even better.  And now, we know that we need a tool that assesses cost to winery for free shipping offers across all states.

3- And through yet another program, we learned that wine donations are good, but unless there is a follow up mechanism to contact event attendees, the value of your donation is dramatically reduced.  And now, we only orchestrate wine donations if there is marketing access to a list in exchange. 

The list goes on and certainly we won’t share all of our secrets, but the bottom line is that a lack of resources forced my team to become creative in their execution.  For lack of tools, we were forced to sacrifice efficiency and continued to launch our programs.  The irony is that in the end, we unknowingly traded efficiency for effectiveness.  I will get my technology, but the technical specs are a bit different now and the existing manual programs will become even more scalable with automation.  My advice: remember that all is not lost without the resources you need.  If you forge ahead, think creatively, and take notes, you just might find the silver lining.

Andrea Johnston, VP Business Development

Posted in Direct 2.0, Project Management

Helping Minds

Tuesday, January 9th, 2007

Have you ever been in a really great meeting? The kind where parties from multiple sides are effectively working together to meet common goals? Last week I had the pleasure of participating in one of these. I didn’t even realize how impressed I was until afterwards.

One of our clients invited us to participate in a planning meeting for 2007. They shared their very concrete goals for the growth they expect to see and asked us to help get them there. Simple. But not inherently easy.

I’ve often noticed that people can have a difficult time asking for help, especially in our society. A common fear is that you will be perceived as weak, or in a work environment as not knowing your job and therefore are expendable. My experience has shown me, however, that the opposite is much more true. Seeking assistance can bring tremendous rewards and as someone who is not naturally inclined to ask for help, I have found this to apply both personally and professionally.

I recently read a post on Collective Intelligence and recognized that happening in our meeting on a smaller scale: individuals with varying strengths and areas of expertise contributing to propose solutions to a set of challenges.

It’s easy to sit in a room with the same group of people with whom you’re familiar and discuss the same issues you’ve rehashed over and over, you just may not get very far from where you’ve been. While it can be unnerving to invite in “outsiders”, the leaps you may make by challenging your usual ways of thinking can be inspiring.

For our winery client partners, I offer the following steps:

  1. Review 2006, successes and areas for improvement.
  2. Brainstorm where you want to go. Take the risk and write down some big dreams.
  3. Identify measurable goals. Stretch yourself and make them impressive.
  4. Share your goals, concerns, and expectations with your IBG account manager and together form a plan to achieve your objectives.

This process will foster a great partnership going forward, one of mutual trust, accountability, and collaboration.

In any arena, I encourage you to solicit opinions from unexpected places, even from people who have little direct knowledge of your industry.That business-savvy sister-in-law may surprise you. Go outside your comfort zone and be open to a whole new approach. There are major gains to be made with virtually nothing to lose.

So while we didn’t solve the world’s problems in our 2 hour meeting last week, we did set the stage for a terrific year ahead, one of partnership and understanding. We’re all set up to succeed!

Natalie Douvos, Sr. Director, Product Management

Posted in General, Project Management

Keep It Alive

Friday, December 22nd, 2006

My Launch Department has spent months streamlining our client launch process (taking a website from contract to going live), and we were able to become more and more efficient, and able to launch sites faster and faster.

We worked very hard for months and thought we couldn’t make the process any faster until…

In one of our department meetings last month, someone on the team half-jokingly said (in these exact words) “why don’t we just move this here and move that there. BAM!” When he did that, all our eyes started to glow and we saw something that none of us had seen for months and months. We were able to cut our launch time in half in many cases and extend our QA time to test out the sites more thoroughly by simply moving 1 task elsewhere in the process.

The lesson learned here is that a process should never be “dead”. It’s something that is alive, and can be improved upon and changed at anytime to produce better results. We are now starting to look at other processes we have in a different light, and trying to see how we can dramatically improve them.

Happy holidays everyone!

Eric Hsu, Chief Style Officer

Posted in Project Management

Play Well With Others - Secrets to Effective Launch Management

Wednesday, September 27th, 2006

•Bring suggested solutions with the problems to the meeting table.

Identifying problems. That’s the easy part. Thoughtful launch solutions are the challenge that will earn respect and admiration from your launch team.

•Your verbal and nonverbal communication matters… We are all radar machines that constantly scope out our environment. Respect for people on the team is a hallmark of a successful launch.

•Develop Trust. Trust is the basis for much of the environment you want to create in your work place and on your team. Trust is the necessary precursor for feeling able to rely upon a person, cooperating with and experiencing teamwork with a group, taking thoughtful risks, and experiencing believable communication. ”Trust men and they will be true to you; treat them greatly, and they will show themselves great.” –Ralph Waldo Emerson

•Keep your commitments. When launching a web site, work is interconnected. If you fail to meet deadlines and commitments, you affect the work of other employees. Always keep commitments, and if you can’t, make sure all affected employees know what happened. Provide a new due date and make every possible effort to honor the new deadline.

•Share credit for accomplishments, ideas, and contributions. As a launch manager, I take the time, and energy, to thank, reward, recognize and specify contributions of the people who help you succeed. This is a no-fail approach to building effective work relationships. The leaders who work most effectively, it seems to me, never say “I.” And that’s not because they have trained themselves not to say “I.” They don’t think “I.” They think “we”; they think “team.” They understand their job to be to make the team function. They accept responsibility and don’t sidestep it, but “we” gets the credit…. This is what creates trust, what enables you to get the task done.

•Help other employees find their greatness. Every member of the launch team has talents, skills, and experience. As a launch manager I try and help the launch team harness their best abilities. I compliment, recognize, praise, and notice contributions from each team member.

Winning is important to me, but what brings me real joy is the experience of being fully engaged in whatever I’m doing. As a new launch manager at IBG, it feels great to be playing on the right team. IBG , as a company is about more than empowering wineries to sell direct and measure the performance of their sales but it’s also about excellence, respect for others, and ability to make people happy. Some call those things a “soul.” The IBG team is one of the most creative and driven teams I’ve ever worked with. I know together we can accomplish just about anything. Work can’t get any better than this!

Mattie Schutz
IBG Launch Manager
launch@inertiabev.com

admin,

Posted in Project Management

Project Management in the Details

Tuesday, May 23rd, 2006

Project management, but definitions vary. It often reminds me of the old story about the blind men and the elephant — each has a different description of what an elephant is like.

In a way, that is part of the role of the project manager — to take all those differing perceptions and synthesize them into “the big picture.”

However, the project manager often needs support from those observers — clients, account managers, engineers — in order to make sense of what is going on and to help make decisions about how to process that information.

I’d like to make note of some of the little things that help improve work efficiency for everyone, which may seem obvious but which are essential to proper communication and establishing repeatable, dependable processes:

Use a proper e-mail subject line. This seems shockingly obvious but think carefully about how your subject line helps or confuses people. In environments where you have many clients, or where your vendor has many clients, using specific and concise language can help immensely. Instead of “where’s our widget?” try “Client X - Where’s our widget due on ___ ?”

Indicate what you want from those you CC: on e-mail or meeting requests. I’ve seen e-mail discussions go from 3 to 10 people in little time, filling up mail boxes and causing confusion. If someone is added as an “FYI” — forward them the e-mail once you have sent it, unless you expect that person to comment in the discussion.

Label your documents. This may sound funny to you — of course you know what current_project.doc is — but did you include that information inside the document? Include details like the title, created by, date updated, and page numbers — someone may print it and then not recognize the information (or version!) later.

Establish meeting agendas prior to a meeting. In my opinion, meetings lose their effectiveness after 30-45 minutes. Unless you are brainstorming or making a presentation, break down your issues into an agenda that can be addressed in 30 minutes. It makes for more manageable meetings and you’ll find that follow-up to action items generated during the meeting improves.

As a project manager, it is my job to ensure that projects move forward on time. I do this by checking on receipt of deliverables, watching timelines and doing my best to guard against duplication of effort. Support from my team by way of clear communication is essential.

— Jennifer R. Accettola, Sr. Project Manager

admin,

Posted in Project Management