Project Practitioners > Guiding, Not Micro-managing Projects Part Two

Guiding, Not Micro-managing Projects Part Two

By Niel Nickolaisen

Last month, I wrote about how I shifted from a project management process that defined, to the nth degree, what I expected project managers to do to a process that gave higher level guidelines and let my project managers use their brains.

This month, I complete my list of project management guidelines. So, without further delay . . .

Project duration. In his book “Rapid Development”, Steve McConnell presents research that shows that projects that last a long time and attempt to deliver a large number of “functions” rarely succeed. However, projects with short durations that deliver a low number of functions, fewer than 100, rarely fail. So, my rule of thumb is that no single project should last more than 90 days (and the shorter the better). In practice, that means that if I am managing a large, put-the-business at risk project that will last longer my 90 day limit, I need to break it down into shorter chunks. Same for function counts. For large, complex projects, I break them down into chunks of fewer than 100 functions. As an added benefit, shorter and less complex chunks also mean that we can adapt to change. In today’s rapidly changing environment, how much does the world change underneath us while we work on a 9, 12, or 18 month project?

In “Rapid Development” Steve McConnell also describes how saddling team members with concurrent tasks reduces productivity and effectiveness. In other words, if I am expecting someone to work on multiple tasks in parallel, I am setting them and the project up for failure. As I look at my life, this just makes sense. I get battered with parallel tasks throughout the day. Needing to work on a report while attending meetings while answering email while answering the phone while et cetera. Many days, I have so many parallel tasks that I don’t get anything done. My project guideline is that no one is assigned concurrent deliverables. Let them focus on a task, get it done, and then move on to the next deliverable.

One of my early software development mentors taught me an important lesson. No one knows what they want until they can see it. The associated project guideline is that the first step in the project is to turn requirements and requests into a prototype as rapidly as possible. Our customers can use a prototype to tell us what they really want rather than try to envision how they will use the text in a requirements document. I have found that, as long as I set the right expectations, the rapid prototype does not even have to be that good or complete. It just needs to be good enough that a customer can give us the feedback we can use to continuously refine the requirements. Rapid prototypes dramatically reduce the development cycle and nearly eliminate the likelihood that we have missed the boat.

There they are, my project management guidelines. I train my project managers on these guidelines (the training lasts about 15 minutes) and then unleash their creativity on how to use these guidelines on their projects. I don’t tell them how to break a project into chunks nor do I tell them the desired format for a prototype. I expect they know the “how” much better than I ever could.



Related Links
These Software Requirements Capture Guidelines condense 20 years of software exec experience into detailed guidelines for documenting things throughly before you start development. If you prefer a more agile approach, you may want to try requirements cards as used by methods like Scrum and Extreme Programming. Either way you go, it's a good idea to start having review meetings as soon as possible.


Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

I completely agree on the need for getting something in front of the customer early. Written documents can never fully describe the interactive and visual representation available from a prototype.

Early and frequent feedback is essential for successful software development projects.


The comments to this entry are closed.




©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy



Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds


Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.