I am currently trying to transition from the world of managing mainly IT infrastructure projects to the world of software development projects. In doing so, I have run into some confusion related to the numerous software development methodologies (see http://www.cetus-links.org/oo_ooa_ood_methods.html).
I have been a student of PMBoK for several years. As I read about all these OOA&D methods, I see a great deal of similarity in many of them (like RUP) to the more general PMBoK Guide. However, I must wonder why there are so many versions of virtually the same process in this single industry?
Many job postings specify a need for experience with a particular methodology or tool set. So, where should I start?
Joe Saving Changes...
Sort By:
Michael BrownProject Manager| JPMorganChaseDeerfield, Il, United States
Joe,
Just "my humble opinion," but what the Guide to the PMBoK provides, is a rather generic PROJECT MANAGEMENT process, applicable across a wide variety of industries, situations and the like. You'll find carpenters, movie producers, not-for-profit organizations and such using processes from PMI to help guide their projects.
At the same time, RUP and other similar methodologies are more atuned to the world of Information Systems Management, and are sometimes classified as System Life Cycle Methodologies. In fact, OOA&D consists of Object Oriented ANALYSIS (usually the requirements analysis / gathering part of a project) and "D" or "Design" - usually the "build" part of the project.
There is a very natural connection between OOA&D, RUP and the Project Management Processes that help govern the Initiation, Planning, Execution, Control and Closure portions of the project. It's really not a case of either/or, but how you can use RUP and OOA&D techniques and tools within the greater PM context.
Hope that provides some food for thought! Saving Changes...
All projects that are defined by promises associated with time, scope/quality, and budget can be fit into the overarching processes of the PMBOK guide.
The "methodologies" that one hears of most in the software world are more about how the work is performed. I tend to think of them as processes for "task management." They define how the work associated with tasks within a project is performed.
Defining the work to be done (planning) and tracking progress to assure that promises are still deliverable, i.e., the domain of project management are obviously influenced by the type of work, but there is nothing in the "numerous methodologies" that is inherently inconsistent with basic PM processes.
Now there may be some aspects of these methodolgies that are a difficult fit into traditional CPM, such as the iterative nature of many of them. But if we define PM processes to include the more recently introduced Critical Chain approach, with it's buffers that can model expectations of variation in iteration as well as in task duration, even that concern goes away.
As with Michael's response, this is my "humble opinion."
Lots of humble opinions out there! Here's mine: the PMBoK defines the PROCESS of project management and the other methods describe the development of a PRODUCT. So, PMBoK describes the commonly accepted method for HOW we do the work, where the various methods define steps to create the WHAT. Projects are all unique, because they produce a different WHAT each time. However, the processes used (the HOW) may be very similar for verious industries. The reason there are so many different methods, is because there are so many different PRODUCTS. What works in one industry, or even for one organization, will not work for the next. Usually, the difference in the methods focus on quality and application of techniques. Some techniques are easier to apply in one set of circumstances. For example, an evolving prototype technique works well when the organization has the right software and processes. This may work well in a Web development arena, but may not work well in a transaction oriented situation. So, when selecting a methodology, it is important to read beyond the steps and tasks and get into the techniques and assumptions behind them. Select the methodology that best fits the needs of the PRODUCT. Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Joe, excellent post and very good replies from Roger, Frank, and Michael - they are pros. I would only add that many companies are viewing project management as a discipline and skillset to be used when needed throughout the company and not just confined to the IT department or the project office. As such, the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) is the recognized de facto standard for project management. It can be applied in IT infrastructure projects, software development projects, commercial-off-the-shelf (COTS) projects as well as in other project efforts such as product development, research, human resources, sales and marketing, etc. Hence there are many approaches out there. For many organizations, you will find at a minimun a core PM process, typically aligned to the PMBOK, an SDLC methodology like Waterfall, Agile, or RUP, and a change management process typically used with a change management tool and in support of the organization's operation support team. And for larger organizations, you might find several PM processes and best practices to best meet the needs of different project types and efforts. In terms of where to start, it wouldn't hurt to have a working knowledge of all of the major models and for your given area of expertise, job position, or duties to have a thorough understanding of the leading approaches. Good luck. -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
"I do not know anyone who has got to the top without hard work. That is the recipe. It will not always get you to the top, but should get you pretty near."
