Project Management Blog

Well, I’m as swamped as I’ve been in a long time, thanks to a business trip to Illinois to work with a University on commercializing a beautiful market maker website and technology for agricultural users. This was a great trip, and here’s a mish mash of lessons:

1. Universities are an untapped market. Many of you who live near universities should consider stopping by some departments to discuss potential projects for outreach to constituents. In two days, this particular university department (agricultural extension) received requests to create a bunch of sites that will become the “go to” sites for a variety of natural resources and recreational research. They can’t do any of this on their own, and need people with good ideas to help create commercialization (e.g. advertising and premium membership) models.

2. Part of the trip involved pitching to a local venture capitalist. I helped develop the business plan and pitch. If you have yet to pitch to a VC or investor, make it part of your goals. It’s fun, exciting, and you get great feedback (or brutal feedback). In this case, the VC thought he knew what we were pitching, but didn’t. Our mistake was going off script instead of sticking with our key themes and “story.” But we also learned that this particular VC has a different mission than our particular venture, and so the fit is not there.

3. During the trip, 2 other prospective clients reached out to me, adding over $50K to my pipeline. When you visit a large organization, try to get visible while you are there walking the halls. In this case, my client sponsor helped me get visible and was very helpful in this regard.

4. Don’t underestimate your value. Sometimes I take what I do for granted, like helping people get organized and move forward to grow a business. But the client found this enormously valuable, and helped me think more about the value I bring, so I can describe it to others. Nothing beats having your own clients tell you how to describe your value to others.

5. During business trips, find time to do other work so you aren’t overwhelmed when you return, as I am now. I just hung out at my hotel room, when I could have done a better job catching up.

Okay, back to work…..

This article provided by sitepoint.com.

Here a a few ideas for those of you looking to get your first client, although these ideas apply to anyone at just about any stage of development:

1. Write down the names of everyone you know, everyone. You should be able to get a list of 100 people. Use some techniques to “jog” your memory. For instance, go throught the phone book business pages and list anyone who is a specific professional you know (accountant, architect, etc. all the way through to the z’s). Include your neighbors, your family, your former employers/colleagues, people you play sports/hobbies with, people at your place of worship, and so on. List people with red hair, people with good senses of humor, people named tom, and on and on.

Then contact these folks, tell them what you are doing, and ask them to make connections for you. Ask them specific questions, like, “Who do you know who recently started a business?” Then follow up with those people. Either they will need a web site or redesign or they can refer you to people they know.

For every door that closes, try to open 2 more doors by asking for two more names.

2. Target some visible local businesses. Check out there website. Send them by mail a 3-page report assessing their website and providing ideas to improve it. Then follow up to meet and discuss how they can use your ideas to get more business.

3. I borrow this idea from marketing consultant David Frey, and really like it. Take a page from the yellow pages where a prospective client has a listing. Get that page blown up to a poster 2-3 times its current size. Circle the names of competitors of the prospective client. Write a letter that says, “I’m going to help one of the companies on this page dramatically increase their business and market share with a dynamic, leading edge website. I hope it’s you, and not one of your competitors!”

There you go—3 great ideas for free. Ideas are cheap for a reason. It’s action and follow up that are valuable. So get moving.

This article provided by sitepoint.com.

Studies show that physicians generally start out in their career ordering too many tests. Then, as they get more experienced, they order fewer than average. Their gut instincts have developed, and they get pretty good at diagnosing patients without a bunch of unnecessary tests.

While on the train heading to Paul Graham's Startup School, I brought along quite a bit of reading material. I was hoping to sleep, but I was also hoping to catch up on some reading while I couldn't be distracted with various tasking, email, etc, etc.

For example, the first thing I read was an article on "Software Development Cost Estimating" and I dug into it with interest. I happen to have a very particular way that I do my estimating - which seems to be quite accurate by the way - but I'm always looking out for more and better methods. This wasn't one of them... let me analyze this one step by step.

In the September/October issue of IEEE Software, I came across an article titled "Why Context Matters" which gets to the difference between functional and non-functional requirements and how the two interact and are interdependent.

Functional requirements are normally taken to be those hard and fast rules like "the speedometer must accurately report speed to the user." Everyone in the industrialized world has a pretty solid idea of what it should do or how it should work. Therefore, there isn't much room to wiggle.

Non-functional requirements are much more "squishy" and open to interpretation of the people capturing the requirements, the users, and those actually implementing the functionality. A rule like "the speedometer must report speed in an easily discernible manner". Wow, now we have lots of room to wiggle, which way do we go?

This is where the Context comes into play.

This being my first entry to the project management blog I want to introduce myself. I have 10 years of professional software development and programming experience but I am relatively new to actually perform project management - closing in on two years. In my blog entries I will try to share some of the experiences I have had during my first steps in this job and what I learned from them. I will also share some tools, processes, best practices, and so on - at least these things have worked for me so they might work for you, too. Do not take my words to be the one and only truth because each project manager has his own management style but there are tips, tricks and tools that might facilitate the project manager job for many.

There is an old saying in software development about how the only bug free line of code is the one you don't write. While this may sound pessimistic, the motivation is to curb a developer's urge to over engineer a solution. When it comes to Project Management, do we have a corollary to this wisdom?

I believe we do, and it is this: The unnecessary meeting that is cancelled retains productivity. (Or at least, it has the potential whereas the meeting would have certainly doomed the group to wasting an hour)

Meetings are a necessary evil. This is so because good software requires communication between developers and stake holders, but meetings should ultimately be seen as overhead. If five people are in a meeting for an hour, this represents five person-hours not spent on features or fixing bugs. Scott Berkun, in The Art of Project Management, goes a bit further and warns against recurring meetings, which often outlive their usefulness.

There are several ways for a Project Manager to keep developers out of meetings:

• Sit down with developers and stake holders separately and confirm if all expectations are met. A five minute discussion with both parties separately may save everyone from a longer project review session.
• Start eliminating recurring meetings, or convert them to opt-in meetings, decided by the Project Manager
• Structure the order of events in a meeting so that some persons may leave early. Don't make developers suffer through a budget discussion if all they need to do their job is clarification on the software requirements.

Before you get too slash-happy, do keep in mind that effective meetings can add value. A Project Manager should enable developers to produce software. If the meeting doesn't serve this goal, adopt some meeting elimination tips from this article.

Over the weekend, I was discussing a couple projects with the highly esteemed Nola who happens to work with me over at CaseySoftware and a regular contributor to CodeSnipers. She was putting together an estimate for a company on a complete site redesign and functionality upgrade and was having problems putting together a solid estimate. In the meantime, I was in the thick of putting together a pair of RFP responses, so I thought I'd share my tactic for getting solid estimates:

Break everything down to the smallest steps/pieces you can.