Meeting Minutes with Agreedo

Most people agree that good meeting minutes are extremely valuable. It is always important to follow up verbal agreements with writing, and to remind people, once they leave the meeting room, of the action items. Now, you can rely on people's memories and their own note-taking, but I wouldn't advise that if you're a project manager.

I just checked out Agreedo, presumably the name has less to do with "Greed" than with "Agreed". It is a tool to set up meeting agendas and take meeting minutes. I would like to review its functionality while discussing other alternatives for achieving the same goals.

Agreedo allows you to set up a meeting and invite attendees, who can then add to your agenda. You add items such as "Information", "Decisions", "Tasks" and "Topics". Topics seem similar to Information, but they have an icon to make it clear that there will be children discussion items. Meanwhile, all of these items can have indented items beneath them. In addition, items can have comments attached – which can become an ongoing discussion between attendees.

Another interesting feature is the ability to "Start Meeting" and see a running clock of how long you've been meeting. It even turns red when you go over, a common issue around here.

When finished, you can export the items to Excel. You can also refer to Decisions and Tasks later, in a list that is meeting-independent. Personally I put all my decisions and tasks into similarly named SharePoint lists on my project SharePoint site. Of course, that does take work! Another option for me would be, using OneNote, to create Outlook Tasks – but that doesn't allow you to assign actions to others.

Overall, the functionality would be perfect as a feature for WebEx or another online meeting tool. As a standalone, I don't see myself using it. I would prefer to continue using OneNote, or in some cases, a Microsoft Word "Meeting Minutes" template. I guess I'm just old-fashioned, but it doesn't seem that difficult to me to organize my meeting minutes into Action Items, Decisions, and Discussion – I don't need the overhead of a new tool. The idea, however, of keeping meeting minutes in the cloud is surely appealing.

Project Management … Applied

In the world of Softerewa

In the world of Software Project Management, a gal can get down on herself. Software is notorious for its late-running schedules and complex systems where every little thing that can go wrong will. So it was an excellent experience for me to apply my project management skills to something completely different. This year, I successfully created, produced – and even performed in – a holiday pageant that raised money for Cradles to Crayons, a local organization helping homeless children.

I couldn't believe I was doing something so big – after all, what did I have to bring to the table? Having never done this before in my life, I planned for small things, a small theater with a small financial investment, small expectations for the event, and small demands on my cast. After all, it was the very first time I was doing many of these things. Sure, I can dance – but I had never choreographed for more than two people before. I hadn't written and directed a show. I hadn't even acted in any community theater since I was eighteen. I certainly had never asked people to put their faith in me, first the performers who agreed to put in hard work and effort into this newborn show, and the audience, who had never seen a show like this – and not from me. I guess it is something like when the Angel appeared to the shepherds and told them that the son of God had been born in a stables nearby … except when I asked people to do something extraordinary for me, I didn't have the benefit of a halo and wings.

Risk management came in handy. I have seen other shows – of less complexity – succeed and yet have failures that I did not wish to repeat. A late-running software project is one thing – that some people come to expect. A late-running show with audience in their seats? Unacceptable. I have seen dance shows where performers have not appeared to perform – and when you have a story to tell – you cannot simply have a cast member bail out. So that was definitely a concern – and not one that I was able to mitigate with understudies. Rather, I got incredibly lucky that the one cast member who was injured in the week prior was replaced by another gifted performer who picked up and improvised with the outline she was given during Dress rehearsal.

With encouragement from my co-producers, we forged ahead, even when things seemed darkest, like when our original choice for roles were injured, when we lost the full involvement of one co-producer for a time, or when only a few people showed up for auditions. Bravery was required when I signed the contract with the lighting/sound technician, knowing that my nightly anxiety attacks would end (and they did) once I knew that we'd have that taken care of – but committing a large portion of my expected proceeds to this cost – the first one I couldn't just pay out of pocket. Even as an IT project manager, I had rarely dealt with profits and expenses so closely as I did on this show, knowing that failure meant not only a loss of reputation, but also loss of my own invested money. I had to evaluate each thing against its effect. Would particularly pretty tickets persuade more buyers, or could we get by on the cheapest ones? [We got the cheapest ones!] Were flyers worthwhile printing, or was it better to advertise with a digital flyer in email? In most ways, we scrimped and saved – and the strategy succeeded. The one place we spent money was the aforementioned light and sound tech, and when I saw the theater setup, I knew we had spent our money well. If we did not hire him, we would have had no way to project sound and we would have had no lights at all (the house lights and stage lights were one and the same).

The show was documented six ways to Sunday. I sliced and diced the data in different ways, according to the recipient of it. The lighting/sound guy had his cues, the stage manager another. We had spreadsheets of costumes, spreadsheets of props, spreadsheets of ticket buyers. Google Docs was an incredible resource, allowing me to create documents of all types and share them – collaborating with my team.

My technical expertise came in handy with setting up the website, along with the PayPal ticket purchases, as well as the collaborative Google site for the cast to communicate.

So it is with amazement and pride that I look back at the show I produced two weeks ago. Thanks to the hard work and diligence of all, we had a seamless show in a nearly sold out theater. We raised more than my expectations for the charity, and it was very well-received by both the local community and the dance community. It made people feel spiritual and connected to Christmas, and it raised cultural awareness of Middle Eastern cultures too.

The special thing I had to offer was not necessarily past experience with theatricals, or with event-promotion, of which I had very few – it was my Project Management – my Real Job that allowed me to succeed at this production – which is, as they say, "only a hobby".

Now, it's time for the post-mortem! Happy holidays to all!

Building Relationships

I was catching up on my Projects@Work newsletters, which I've been dutifully auto-filtering into a Newsletters folder until I would have time to read them – and here we are at Christmas with newsletters going back to Octber. I'm definitely finding some gems.

So far, my favorite article is the following:

The Human Element: Janis Rizzuto

This quote here really spoke to me, about the lessons I've been learning this year. I can't say I'm an expert yet – in fact, in most ways, when it comes to leadership, I am a freshman. It's only now that I'm realizing just how important they are. As one of those "logic-based" people (and you know who we are), I believed that people should do things – and things should get done – because they were the right thing to do. Some of us are guilty of treating our co-workers not unlike the machine that we work with – input A, output B, with email as the delivery mechanism. Someone's job may be to do something, so they should do it. Then it breaks down – you sent your input, but you're not getting back the output.

In this environment of limited resources, where everyone is tasked with doing far more than 100%, it's your leadership – and relationship skills – that actually get things done. If every person we walked up to was doing absolutely nothing at that time, I bet the things we'd need to get done always would be. But it's not the case – most people are busy with competing priorities and more work than they can possibly hope to achieve. So, that's where "leveraging relationships" comes in.

"Project leaders need to be constantly building, maintaining and leveraging relationships to get things done. No one is going to care that you are the project manager, so you need to figure out how to broker agreements between multiple stakeholders to move things forward. Part of your value to your customer as a project leader is to remove obstacles, and the way you do that is usually not through authority. You have to be creative about how you drive accountability to make sure that people come through on their obligations to the project team." (Janis Rizzuto, 2010).

 

This is my biggest personal challenge for 2011, if I really want to succeed, is to develop these skills. If they are like anything else in life, it's not about a natural gift, it just takes knowledge, practice, and effort. Also, as this article says, you need to pay attention to these as part of your work. Building relationships with others is as important as anything else you do.

Think you are saving big money by offshoring? Think again. You always get what you pay for.

Yes, in the short run, paying offshore developers 25$/hr may seem like a great deal.  However, companies must be aware that there are a number of hidden costs.  Some are avoidable if you know the cause.  For example, you might have an on-shore person spending a lot more time managing the engagement, taking more time to detail requirements - as much time as they may have previously spent on building the application in-house.   There could be costly errors if the offshore developers do not understand the business needs and requirements; this can be corrected if you have an on-site business analyst and/or if you can connect your off-shore team with your stakeholders.  However, the problem that many US managers complain about  is Quality - whether the off-shore developed code is maintainable and working - or is it spaghetti code and full of bugs?

If there are any quality issues, your on-shore resources will be discovering them, spending their much more expensive time debugging, reporting issues, and so forth. 

I'm currently managing a project where a vendor is developing customizations off-shore.  I'm not sure what kind of testing they are doing, if any.  I do know that we get their code deliveries, myself and a number of other highly paid business people are spending many cycles testing and reporting issues.  I know the vendor was selected because of their low prices.  But if I had it to do again, I wouldn't.  In fact, I'm incredibly overjoyed that by a stroke of good luck, my other current project has gone from off-shore resources to - not only on-shore but on-SITE resources.  The progress that can be made when the developer can show his prototypes and talk directly with the stakeholders is well-worth the cost.  It all comes down to - you get what you pay for.

I don't have a problem with non-American developers, as some do.  I'm not xenophobic and I'd be happy if other countries reached our same standard of living.  But over the years I have been a consultant or have been  managing projects, I have seen that on-site, co-located development teams are far more effective.  It doesn't matter what their background, race, or ethnicity is - it's all about whether you can talk face-to-face, be on the same timezone, and - in the case of quality issues - can make them accountable for their work. 

If you really want offshoring to work, there are a few things you might want to pay attention to:

• Make sure your offshore team has really good phone connections.  Even with the best English, if the phone connection is poor, communication will suffer. [Insert your language where I used English, which is the language I use to communicate.]
• Invest in good online meeting technology, such as WebEx.  The ability to share screens and voice conference is so important, whether you're sharing your requirements, or seeing a demo of something they have built for you.
• See if you can establish at least some shared hours, if your on-site and off-shore resources will be working together.  It can be so frustrating waiting 12 hours for an answer, or if you can never talk real-time at all.
• Try to have someone from the offshore facility come to your site, meet the people s/he will be working with, and learn about the business.  It will personalize the people that are working together, increasing cooperation and communication. And obviously if your off-shore people are working on or supporting business applications, it helps if they have some context.

And remember - contrary to what I recently read in a business textbook - programming is not like digging ditches.  One programmer cannot simply hand off his train of thought, creative process, and so forth to another programmer at the strike of the clock.  You are not going to have a magical 24 hour development cycle.  Instead, you will have various 8 hour development cycles going around the clock.  Now, if you have a service desk, you might get this.  But not with software development.

I have trouble keeping up with this blog, although I have so much to write about.  I have switched to a new group within my company, the newly formed Program Management Office.  I am back at Brandeis again, taking a class in Agile Project Management, which has proven very interesting - and inspirational.  Now, recall, I thought I hated Agile because I thought it was all about lone cowboys and no planning.  Finally, I have a new project in my life for about the six months, and the iterations of this project stretch far into the future, with no end in sight, and plenty of features on our product backlog.

This little dude came into my life in August of last year.

& of course I put him right to work.

What Business can learn from XBOX 360 Achievements

When the XBOX 360 came out, it added a new dimension to gaming – Achievements. For those who are unfamiliar, I will explain. Achievements are earned through playing games, either through the course of playing through an adventure, or to celebrate certain feats of gaming – 25 headshots in a shooter or playing through the game at a certain difficulty level. When you accomplish an achievement, it pops up on your gaming screen and later you can view all your achievements for all of your games on your XBOX 360 profile. On top of this, your achievements are visible to others and you can compare yourself to your gamer friends to see who did what.

It's an amazing motivational tool. Like many people, I play games for fun. I play a game the way I want to play it, usually only once. However, with achievements, that has changed. I find myself looking up what the achievements are and spending time trying to get them, even if it means I try things I don't normally try. It forces me to explore the game more fully, even to play the game multiple times. And it's surprising how much I care about those little medals of honor.

It's not unlike star stickers that we might use for children's chores, or rewards for good behavior. Can anyone explain why a little one gets so excited about a gold star sticker? I remember earning them in a math class – nothing made me want to do math more than the recognition that I had worked hard in the form of a little star.

It works so well for children. It works so well for gamers. Why don't we try it on professional white-collar workers? Imagine if a project manager came up with a list of achievements. Some would be standard project achievements – as the team progressed through each stage. Other achievements would be for an impressive performance, completing QA with all critical bugs fixed, for example.

One important aspect of Achievements is Awareness. If you don't know what they are, you can't strive for them. Most of the time, the team knows the phases of the project, but how often do they have a way to measure how well a task is done, let alone a goal to strive for?

The second important aspect of an Achievement is Visibility. If you have a co-located Agile team, you already use a lot of visual artifacts. Why not an Achievement posterboard? A SharePoint site or other collaborative team site offers a virtual location. Another option could be part of the presentations at the project close-out.

Sometimes, we business people can learn from our leisure time. This time, the XBOX 360 taught me something valuable about motivation.

Salesforce.com for Rapid Application Development, particularly for non-profits

In these lean times, more and more companies are turning to turnkey solutions. However, many companies – like mine – prefer the ability to customize their implementation. Sometimes turnkey solutions can be limited. However, systems that are built from the ground up not only increase the project timeframe, but they also can become a support nightmare. Each new application has a new user interface, new administrative functions, new support documents, and sometimes the original programmer ends up supporting so many of his homegrown applications that he or she has no time to write new ones.

I speak from experience here. In my present capacity, I inherited over 30 homegrown applications written in ASP.NET.

To me, Remedy was always the perfect solution for these companies. Here you have a workflow system that is extremely customizable, yet offering extremely rapid application development. For support, it is not difficult for a technical person to read and understand remedy 'code', which takes the form of visual elements within the Admin Tool (forms, filters, active links, et al.)

However, through a volunteer project I am engaged in with Common Impact, I have become aware of a new (to me) offering. Salesforce.com. This is software as a service, offered through the web to subscribing customers. For many years, I had known salesforce.com as a CRM product, that, by its name itself, served the sales force of a company. However, Salesforce.com has taken a dramatic step – they offer their product free to non-profit organizations. These non-profit organizations can use it to customize an application. It is perfect for contact management, help desk applications, and simple asset management. Even more advantageous for the struggling non-profit, it does not require an on-site installation – it is hosted.

Currently, my assignment on this project is developing a simple web interface for end-users who wish to create help desk cases or asset requests. At first, I thought I would be building this on my own – until I discovered Salesforce.com offers a 'web-to-case' feature that eliminates most of the need to write custom code. Peter Martin writes more about using the web-to-case feature in his blog, Cloud Clout.

I'll write more about Salesforce.com as I have more thoughts on it.

Also, look forward to a discussion of the new BMC Remedy Action Request System 7.5, with an all new administrative and development interface.