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

In developing a project management methodology or project lifecycle, it makes sense to look at the most popular methodologies in existence and try to see what they have in common, what they share, and what would be a potentially good starting point for a new project management methodology. It also makes sense, I think, to separate the ideas of lifecycles and methodologies. Projects happen in phases (described by a methodology), and work (the development lifecycle) happens within these phases.

With Agile philosophy, things get a bit more interesting (and effective?), but for sake of study, I will not go down the Agile road in this article. It is an almost entirely different animal and although I assume Agility, to some degree, within the SDLC – it is a Discipline more than a Methodology.

Every organization is different, and every business maintains a different level or human capital, resources, infrastructure, and on and on and on. It is not surprising, then, that over the years and with the specialization of industries, there have evolved several types of project management methodologies, each with it’s own unique slant towards a specific niche.

Among project managers in the USA, the PMP is the most respected credential. Few in the USA have heard of Prince2, while in Europe and particularly in the financial industry, Prince2 is the standard. It seems as though there are four major players in the project management methodology arena; PMI, Prince2, Microsoft’s Solution Framework (MSF) and IBM’s Rational Unified Process (RUP) are the heavyweights and although derivatives of each exist (particularly with RUP and agile development), we could use these four as a baseline for comparison without making too much of a leap of faith or straining our imagination to the point of discomfort.

I think it is important to consider that unless you are working at the organization that gave birth to the methodology, no organization will find one of these methodologies to be “plug and play”. If you are working at IBM you will in fact follow RUP from start to finish – but there is only one IBM. If you work at Microsoft, the MSF will be your Bible. I have found that each has unique tools to offer and personally like to make a mashup of them all on more complex projects.

PMI’s methodology states very early in their master text, called The Project Management Book of Knowledge, that the processes detailed within the book are not a methodology in and of themselves. Rather, it would be erroneous to call their Book of Knowledge a methodology. PMI is not a methodology. It is a toolkit. It is a framework for executing projects and covers everything from Human Resource issues to documentation. It lays out a tremendous amount of tools, processes, and subprocesses, but it was designed to be customized. Shops that say they are a PMI shop really mean that they follow PMI guidelines and look to the PMI PMBOK for process description and guidance.

IBM’s Rational Unifed Process (RUP) was designed specifically for software projects. While PMI is meant to be a portable toolbox that can be brought to construction as readily as software engineering, RUP was designed with iterations as specified by what was first called Rational Software and later became part of IBM. The Rational Unified Process is still very well respected and useful within software engineering. Within RUP’s Construction phase, you will find iterations. This is because it is designed for an organization that utilizes an iterative SDLC such as an Agile, Spiral, or Fountain development lifecycle.

The Microsoft Solution Framework originated from Microsoft’s own Best Practices, aimed to help Microsoft Project Managers and developers work with Microsoft tools and projects. It was designed with software in mind, and contains specific entities that are traceable throughout the lifecycle of a project. With the MSF, the software development lifecycle is closely mapped to the project management methodology. They don’t have project phases. They have project tracks. Its an important distinction, indicative of the MSF philosophy, and appealing to me. Still, for simplicity’s sake, let’s call them Phases for now.

The Prince2 project management methodology found root in the United Kingdom’s standards for IT development and has spread throughout Europe to become the most popular project management methodology among IT professionals. Prince2 is very focused on Business Cases and Business Analysis. It may be partly because it arose from a government standard, but Prince2 enjoys particular popularity within the financial industry. Oddly enough, Prince2 has been deemed a good PM Approach towards MSF projects. I read this. I kind of get it, but not really.

So we have identified four major PM methodologies (or schools of thought, to be more accurate and not completely contradict what I have just said):

• PMI
• RUP
• Prince2
• MSF

Each of these schools of thought has its own trademarked definition of what a project is. That is fairly irrelevant here, because we have our own idea and are looking for something to suit our needs. However, I do not want to so easily dismiss the fact that there has been a lot of research put into something that is still as much art as science. In deploying or implementing a project management methodology, I think that the organization must come first and the methodology must come second. Everyone has heard stories of the PMP who came onboard and was surprised to find out that there was no formal Risk Response Planning or Work Breakdown Structure templates in place. Much as I do not believe that a piece of software should dictate the way a company does business, I do not believe that a project management methodology should dictate the way a company manages it’s projects. It should be a resource. Still, there is tremendous value in the fact that countless humanhours have been put into the analysis of a project and we have established a baseline that can be applied cross-industry, cross-technology, and cross-organization. That is because all of this stuff is theorhetical until it is actualized and put into place.

Part of the theory behind project management is that projects are comprised of distinct phases. These phases may contain different processes depending on what school of thought you subscribe to or what your organization has assimilated, but these phases can be found in any project. This is where it gets a little interesting to me.

I have created four diagrams that depict a project as broken down into phases according to the aforementioned four schools of thought:

(You probably want to click that image to view it full-screen.)

So what does this mean? PMI refers to “killpoints” as milestones within a project where one phase ends and another begins. What is relevant here is that by breaking a project up into phases, the project manager gets greater control over the project. In identifying these phases, we create a system of checks and balances where during the project’s lifecycle we can look at the budget, look at our progress, look at what risks and issues have arisen, and manage the project.

I think it is extremely important to recognize that a PLC (project lifecycle) is *not* a SDLC (software development lifecycle). Although RUP and MSF make the two awfully hard to pry apart, they are distinct entities and the project manager outside of Microsoft of IBM will not be managing the software development.

If you look your current PLC, you are liable to see countless places where the SDLC and PLC attempt to overlap and become one massive entity. I think it is likely to be an impossibility and at the very least, is overkill.

There is also overkill in any one of the aforementioned schools of thought. For instance, according to PMI, planning a project consists of the following tasks, complete with their corresponding documentation and signoffs:

1. Develop Project Management Plan
2. Scope Planning
3. Scope Definition
4. WBS
5. Activity Definition
6. Activity Sequencing
7. Activity Resource Estimating
8. Activity Duration Estimating
9. Schedule Development
10. Cost Estimating
11. Cost Budgeting
12. Quality Planning
13. Human Resource Planning
14. Risk Management Planning
15. Risk Identification
16. Qualitative Risk Analysis
17. Quantitative Risk Analysis
18. Risk Response Planning
19. Plan Purchases and Acquisitions
20. Plan Contracting

This is a major reason why I never took my PMP certification test. It gives you a headache to even look at that list. There has never been a need, in my experience, where all these things are needed. Every company is different, and this is a major reason why I believe in the necessity for a customized PM methodology. The people who work at the company, the company culture, the company’s assets, the company’s workflow, and lots of other things will dictate what is useful. When I did work for a non-profit, if I were to have presented them with UML 2.0 Class Diagrams, they would have absolutely no use for them. If I were to present them with a dot notated Requirements Document, it would not be read. They needed plain English documentation and whiteboard JAD sessions. It is not that they were not intelligent. They certainly were. It had to do with customizing my toolset/process to the organization instead of asking the organization to change to match my toolset/process.

What it might make sense to do is look at what each of these schools of thought are identifying as Phases and how the schools of thought ensure project continuity and delivery while moving from one phase to another.

1. It is clear that there is an initial Initiation phase. MSF calls it Envisioning, and Price2 calls it Starting and Initiating, but they are all referring to some formal project declaration.
2. It is also clear that there is a Planning phase. While RUP calls it Elaboration, and Prince2 calls it Planning/Directing, the same sorts of things are going on here.
3. There is a stage where the project receives a Development Handoff. MSF skips this because they already began prototyping as they were planning.
4. There is a period of time where Development is happening. The PM generally gets a bit of a rest here and the SDLC dictates what happens, day to day. Prince2 refers to Stage Management, and within Prince2 a Stage Document functions as a dynamic Project Plan. Stage Control is the control of what is happening as the project is being executed.
5. There is a final phase where the project is formally wrapped-up and receives Closure. It can be called Transtion (as in transition to live), it can be called Deploying (as in the software has been deployed), or it can more generally be called Closing.

We then have extrapolated 5 generic phases from the distinct schools of thought

1. Initiation
2. Planning
3. Development Handoff
4. Development
5. Closure

An obvious question is; where is QA? It is part of the SDLC and so you will not see it here. While the PM may manage the process of QA at our organization, QA is not a PM task. It is a Development task.

Another obvious question is; what about iterations? What about the fact that we hold daily scrums and we dont have an actual development handoff? Still, development happens based on some prompt; in this case it would be the backlog or priority stack. And again, Agile is a little hard for organizations to swallow when they are used to (and sometimes need) the illusion of absolute control.

An equally obvious question is; where are the Use Cases? They are artifacts of the Planning phase, and this brings me to the next issue at hand: how do we move from one project phase to another? What are the milestones? What ensures that what we set out to do is what is actually done and delivered?

The answer is documentation. One thing that all the aforementioned schools of thought have in common is the concept that each project phase has inputs and outputs. That is, I cannot program a piece of functionality unless I know what it is supposed to do and what it is supposed to look like. That is where Use Cases and Wireframes (inputs to the Development phase) come into play. If we take a God’s eye view of the project management process within a technology company, a simple input -> process -> output schema might be as follows:

(definately looks better if you click it and view full-screen)

This is only a partial list of what I have seen to be the most common inputs and outputs. Most of them are documents, and these documents can be templatized fairly easily. You can go back and forth, forward and backward, iteratively. This does not have to be purely linear. You have to extrapolate this a bit. Again, this is only meant to be a guide. There will certainly be cases where a Risk Management template needs to be developed during the Planning phase. There will certainly be cases where a Statement of Work is not needed, since Statements of Work are usually intended for a client and some projects are internal. Nontheless, there is another interesting pattern being displayed here (also present in all major schools of thought), and it allows for project traceability:

(forgive my lack of skill with graphics)

The point is, documentation serves a purpose. It gives people the information they need to do their job. It creates the opportunity for traceability. It creates a baseline. It creates a contract-like descriptor of what will be delivered. It does, and can do, a lot of things. Your outputs from one process become your inputs for the next. They have to be meaningful and they have to serve the greater good (the project and the organization – really, the Business Case).

To put it in a practical wrapper, your wireframes, project plan, budget, Use Cases, and preliminary WBS are what Development gets after they are created during the Planning phase. This way, Design isn’t straight jacketed by the Business Analyst and can do whatever they want, Development is given a set of parameters to work their magic within, and the PM does not have to understand how the System works, as long as it works. Of course, the PM is not required to be oblivious to the technology. They are only required to understand how it fits into the project and what deliverables are associated with it, how to expedite the processes that are involved and measure them against baseline.

I mentioned traceability earlier, and these documents and phases are critical to traceability; they are going to be what makes the project a measurable success or failure. In such a project methodology, we could in map Use Cases directly to the WBS, and then the Development Plan and Test Cases, tying the project together from beginning to end.

I realize that what I have talked about is only directly applicable to technology, and that content development needs to happen along with Systems development. However, I am not sure that content creation is not a separate project from System development with similar delivery dates. I think this should be discussed and probably varies from project to project. If content is going into a CMS, it is a whole different animal than if user experience is driven by content that has yet to be developed. In that case, there is a logic that should probably be documented through some kind of UML and used as an input to the Development phase of a project regarding content.

Also up for discussion: what documentation is valuable to the team? Does Development want UML with Class Diagrams? Does the organization have the human capital required to produce it? Do Developers want wireframes made in Visio of blank boxes and shapes, or a branded wireframe with colors, shapes, and logos? Does Design want to see a Brainstorming document with focus words and websites that the client likes, or do they want to start from a blank slate.

Obviously also up for discussion is the SDLC and the planning of iterations within Development. Timeboxing is an option, as is any number of approaches. Whichever is chosen, it should provide the PM with a way of gauging project progress against baseline.

This is where I think the team needs to examine itself, its resources, and its most effective means of production. The SLDC exists separately, but we should keep in mind that the SDLC depends upon the PLC to a degree, and vice versa.

Essentially, we are

1. Coming up with ideas (projects)
2. Building a plan
   
3. Turning the plan into specs
4. Building to specs
5. Wrapping things up

And we are ensuring continuity and the delivery of a project within scope and within budget by using a steady stream of inputs and outputs along with a baseline and constant scope management.

At each phase change, there should be a formal okay to move forward. Signoff on the Functional Requirements Document might be that formal okay in one instance. There will be times, however, when Planning is done and it is obviated that the budget it way out of reach and scope needs to be cut.

This has been my two cents of the ideal PLC methodology – a staged approach with formal signoff points, documentation that has purpose and use useful, along with constant measurements against the baseline Project Plan should be practical, scalable, and something any given organization can assimilate without too much pain.

Thanks for your time.

Best,

Josh Milane