3 Ways for Small Businesses to Implement Effective Project Management Without Going Insane or Broke

PMI is overkill for your company and you don’t want to hire a PMP, have your organization learn the processes and fill their mind with things that will not be immediately effective and relevant to what they do. RUP is a mystery, and the MSF is way too intense. You read an article on Use Cases and think it makes sense, but dont see an obvious way to start using them and having the ROI on the time that your employees spend writing them return favorably. Rest assured, there is a way to have a definitive project management methodology without having your head explode. Keep these three things in mind and you are well on your way.

1. Project Management is Not Science – it is Discipline.

I think that we can approach these Project Management schools of thought as one giant toolbox. If you are in the software business, the picture below might represent one way in which you could pull elements of Business Analysis, Design, Project Management, into your business processes without needing to be in the limbo that exists between didactic methodologies and an environment where there is no process.

Please click the image below to view it properly, print it out, use it as lining for your birdcage (blasphemy!), etc:

The documents that I picked for this particular handful of early project phases is somewhat arbitrary, but I think that they are the most usable, easy to adopt, and involve the smallest amount of overhead. Of course, as stated in the diagram, you can choose to leave out a Risk Management Document if you wanted to for some reason. There are valid reasons for leaving the document out of your process. There are also less than valid reasons, but I suspect that as you are putting a process in place you know why you are doing whatever you are doing.

2 . The Line Between Business Analysis and Project Management is One That We Draw.

Realize that your Project Manager and your Business Analyst might be, could be, or perhaps even should be the same person. If you are a small shop, you are not likely in the position to pay a full time PM and BA. Unless you only have one moderately simple project happening at a time, you would potentially need several of each. Basic BA tasks are understood to some degree by most Project Managers who have worked in I.T. Most Project Managers have seen BA documentation, and most Business Analysts are familiar with PM processes. I recently had a conversation with a recruiter who called me after reading my blog (amazing, but true) and we agreed that the line between the BA and the PM is somewhat fuzzy in small organizations.

So what do you do with this information? I think the most important part is to realize how much is on your BA/PM’s plate and be sure to support them as much as needed. You cannot buy MS Project and expect to give them everything they need to do their job. Hopefully, communication at your shop is good and you can talk to each other about what resources are needed. You might not even have a Communications Matrix in place (and if you are a small business who spends time on a Communications Matrix, why?).

3. Seperate Your SDLC From Your PLC.

PLC = Project Lifecycle. SDLC = Software Development Lifecycle. They are separate things. They are supposed to be separate things. If you try to combine them, you are going to trip over yourself. In his Better Projects Blog, Craig Brown talks about the importance of understanding particular development environments. I could not agree more. Your organization produces software or websites or whatever it produces based upon some formal methodology and a lot of habits, culture, and organization-specific behavior. If you try to do more than reference an SDLC from your PLC, you are asking for trouble. While I believe in standards and am a very strong proponent of consistency, I am also a realist. I know that Jim the Developer is not going to report back to me on his timebox progress every day because Jim doesn’t get in until 10 and becomes one with his machine until he poops out at around 7. Besides, he reports to his ScrumMaster, not me. Your Development Lead or Technical Lead should be the interface for your BA/PM, but your BA/PM should not try to do much more than communicate with the Dev Lead in regard to things involving the classic Triple Constraint. Beware a PMO that spits out Development Requirements.

Thanks for your time.

Josh Milane

MIT Technical, Boston