By Santosh J. Dubey
Project Management entails practices, methodologies, techniques, people, resources and a host of other innumerable attributes within an organizational endeavour that may or may not be intrinsic to operational needs. While project outcomes can augment general institutional processes as extrinsic factors, they can also lead to critical automation of key internal processes. In today's environment, the ubiquity of ICT resources clearly reflects the need for accuracy in decision making given that factors can be within an organization's sphere of influence (as I define intrinsic). But these factors can verily be extrinsic to these organizations as well; consider the typical Minimal Varible Product practice for the bottom up approach to developing software. As such, a typical project might have intrinsic factors such as resources and people affecting critical operational output but also extrinsic factors such as methologies (Agile / RAD) and techniques (depending on the Project Management factors). These tend to be developed by external industrial trading groups for inter-organizational compatibility. We tend to use extrinsic attributes for operational gains that may or may not be intrinsic or extrinsic, depending on the goal. The need for both aspects to be addressed has led to an explosion of some form of standardization through centralization of terminology with the establishment of nomenclature.
Though I am not a big fan of centralization, standardized nomenclature help in better conforming diverse project platforms to ease communication and management. From my understanding, the clear benefit of this is improvement of documentation. This probably is the reason why methodologies such as the PMBoK tend to be so well-adopted across industries. But that, in my professional opinion, is the archilles heel of this idea - that application of such classifications tend to need to fit across industries as opposed to being natural fits. The PMO is essentially an extrinsic organization to an investing entity. It, across the different methodologies, tends to be temporary and will eventually deliver a deliverable - as such, it makes general sense that the PMO be classified as an extrinsic sub organization of the investing entity. As an extrinsic entity, control elements, such as PMBoK's triple constraints, tend to be difficult to map and address by the parent body. In fact, a project sub organization tends to be judged, in the end, based on the quality and the cost of the deliverable. In Information Systems projects, based on my experiences, this tends to be difficult - especially if standardization attributed to practice methods are rigid. It becomes entirely possible for Information Systems to meet all qualitative goals of functionality and aesthetics yet still fail on compatibility and overall lifecycle value.
This, to me is the biggest issue facing IS projects adopting standardized nomenclature.
If one is to look at the alternative of Agile, it is precisely what PMBoK or ITIL are not. It has worked. The ground reality of IS Project Management is that things change as your project matures, it is a fact of life. Changes in the most successful projects, including those that I have managed or played a role in, tend to be constant - this is so regardless of the level of maturity of project. While CMMi isn't the best gauge to reflect a development phase of an overall SDLC of an IS project, since SDLC should also reflect the overall efficiency of the automation outcome, there is a degree to which software projects evolve. In my personal opinion, the best software projects are those that evolve overtime and constantly change. The easier management of the code, the better managed the entire SDLC. IS Projects must be imperatively written to easily change when needed.
No successful Information Systems project has ever remained rigid and beyond end-user scrunity for simplicity and productivity. And that is exactly what Agile is all about, in fact, I would add that that is what IS Project Management should be all about. But, like other alternatives, Agile practice standards alone is not the answer.
Research suggests that modern projects tend to be susceptible to increasing demand for functionality and applicability at reduced command of resource consumption. That simply means, people today, with automation want more for less. This is a natural predicament, given the technological tools that are so easily available today - however, that said, better project managers simply cannot afford to go by the book for every turn in the project schedule should nomenclature be standardized. Project Managers should realise that there are opportunity costs to each of these features you might want in your application. These functionalities will cost the project sponsor (a PMBoK term) additional resources or might come at the expense of something else. So, the rigidity that one expects with standardizaton, particularly for project-intensive organizations, tends to be somewhat difficult to attain - especially if the PMO of today depends on an extrinsic element to the modern organization that is beyond relative accountability as influenced by project successes/failures.
Bottomline being adherence to nomenclature will also need a trade-off somewhere.
So, consider the question that if trade offs are expected based on the economic principle of opportunity costs for deliverables, how about the trade-offs incurred by a management personnel when managing a large Information Systems project, what about equivalence in resource measurables that ensure project accountability? Do short-term PMOs really need nomenclatures, particularly for non-regular project institutions? If there isn't a need for standardization, particularly if project cycles are shorter and less frequent, would applying less of these standards make decision-making more efficient? But what about the outcome of less standardization that may lead to poor project culture and poorer documentation, as modern project management research suggests?
The rise of Agile primarily points out the need for agility in Information Systems projects. That said, while a civil engineering endeavour cannot be reverse engineered, a software project can be re-visited or have its code amended while retaining its object integrity. In fact, with firm OOP practices, IS projects require a unique management approach that is different from the conventions of typical project principles out of other related yet different industries.
What I have primarily suggested is that IS projects are a little different. They are non-linear and tend to be different to a more waterfall based engineering project such as, say, aeronautics or civil engineering. While fundamentals are project specific, approach to IS software development in projects needs to be more rapid for reduced man-day costs but systems integration projects tend to be more complex than standalone IS projects - primarily due to the complexity of integration of propreitory hardware to customized software and the uncertainty brought on by potential obsolescence and compatibility of key elements such as drivers.
As such, the approach to IS projects needs to be different as the systems tend to be much more fluid in comparison to a tangible outcome of a mechanical engineering project. With proper coding practices, an IS project is the most malleable project form one can imagine, particularly if recommended coding practices are implemented. Research suggests that there is no single element that influences project success (see: ssrn.com/abstract=1952935), as such, the method I best suggest for project management is one that is much more holistic to the goals of the PMO, especially if it is extrinsic to the sponsoring entity. Don't get weighed down with standardization practice needs - because I propose a hypothesis that the extent of project standardization may be proportional to the sponsoring organization's project cycle frequency. Research is underway of course, but professionally, I advise that you stick to something you know can work and has previously worked for you - nomenclature is good if it works, but should not come at the cost of delivery. There is no free lunch, everything has costs derived from somewhere else.
In the end, consider what has worked for you in the past, adopt, to a limited extent, what you know can work and focus on delivering - improvise if you think delivery cycles can be reduced not increased - and implement if a pilot process works. Try it out in a limited context. Big bang implementation might yield negative outcomes. The principle of Agile has been rapid development and flexibility so adopt, adapt and evolve. Linear methods such as waterfall are fine if they work for you - but consider the flexibility afforded by a complex non-linear multi-method approach can bring. This is something I have introduced locally at my company, and it has worked really well for us.