Project Management Blog

Read it on the blog is a project and engineering management discussion blog. A kind of 'Carrie Bradshaw' view of the engineering blogging world, only without the shoe fetish!

The aim of this, my second blog, is to open a debate on what is the most appropriate organisational design for companies that are required to deliver high value operational work alongside high value investment programmes. The blog assumes a basic understanding of functional, projectized and matrix organisations. For readers who wish to understand more about these definitions an excellent overview can be found at wikipedia.

I welcome reader engagement and feedback of your views and personal experiences regarding how organisations structure themselves to deliver the different capabilities of ongoing operations and project delivery. If you wish to comment please click the title of this blog and enter your comments in the box at the foot of the page.

Some options that I have encountered include:

1. Create separate functions for operational work and programme/project delivery, alongside typical support functions such as Finance, HR, Legal, IT etc.

2. Create a single function that delivers both operational work and programme/project delivery, alongside typical support functions.

3. Establish separate business divisions for operational work and programme/project delivery, each division containing all the necessary resources required to deliver its objectives.

4. Establish a matrix organisation, containing functions that are tightly defined centres of excellence alongside a programme/project delivery function that is accountable for defining the 'what' (programme scope), 'when' (programme schedule) and 'how much' (financial plan) by jointly managing resources within the the other functions whose leaders are primarily accountable for the 'how well' (quality).

So now for the 'Carrie Bradshaw' bit

Option 1 may be ideal, providing the demand for operational work, is closely matched to the direct labour resource capacity such that the organisation can meet its required levels of service whilst achieving high levels of resource utilisation. In other words there are no stranded resources or 'fire departments'. But how often does this situation apply in reality? Possibly in the case of organisations that manage continuous processes, but not so for utilities whose assets are exposed to the effects of weather and other external factors.

Option 2, in my experience, is adopted to address the issue raised in option 1 such that, by combining operations and investment delivery, an opportunity for utilising operational resources on project work during periods of low operational activity is provided. But what does this mean for project delivery ? What happens to projects when the organisation experiences high levels of operational activity? How can programme/project managers produce accurate programme schedules when they don't know what resources they have at their disposal ? Does programme/project delivery become the poor relation to operational work?

Option 3, is ideal for organisations whose operational activities and investment delivery activities are dissimilar such as water and waste water utilities and where the demand for work is extremely large. Each division being essentially a standalone organisation.

Could option 4 be a solution to the issues experienced by option 2? Establishing a professional programme & project management department within the investment delivery function. A function whose accountability is to deliver the organisation's investment programmes utilising a common programme management methodology based on best practice and the needs of the organisation. Could this be achieved whilst maintaining a close relationship with the other functions in the organisation through joint management of resources? Is it possible to be 'best' at operational work AND project delivery, or does one always succeed at the expense of the other?

I welcome all views, especially those relating to utility industries, please comment.

My conviction, from the past learnings, especially in managing people is, we need more than just skills and experience to deliver.

I will start with 3 major buckets when looking for resources in a project team. For that matter, into the organization.

Skills are the knowledge elements required for the job. You advertize them prominently. Experience is obvious which is also advertized prominently. The last, but most important one, which is often not even realized and recognized is, the Quality.

I will define Quality as the personal characteristics of the individual. Definitely, there are many of them to make a large list. And they differ from role to role.

For example, a project manager is expected to display maturity, patience, commitment, trust, integrity etc., Whereas, for a developer, focus may not be on these kind of characteristics but on generic ones like commitment and attitude. As you can see, Qualities are distinctly different from Skills. They can't be taught in school (or, probably can be!!)

The point I am trying to emphasize is that, every job requires some of these qualities, varying in number and degree from role to role. The organization must list, define and assign them to each role. AND, don't just stop here. When bringing in someone into the system, check their qualities which are expected for that role, just as you would check the guy's skills and experience. If someone doesn't have it, don't take them in.

I think you'll have a wonderful system in place. You certainly don't want people who lack commitment, even if they are having the best skill and tons of experience.

However, the challenge will be to try and evaluate these qualities when interviewing people. Some food for thought for the HR function?

Project Management is perhaps one of the most fiercely debated and grossly misunderstood disciplines in the software field currently, hence let me throw in a disclaimer first: if you are a small team of experts and/or people well-known to each other (e.g., have worked together as a team earlier), and situated in a collocated fashion, doing a lot of ‘creative work’ that can’t be very ‘accurately’ scoped, let alone managed; you probably will find ideas of formal project management a huge overkill (on time, effort, money and might even seem to stifle creativity), and you might be better off considering ‘lightweight’ methods like Agile Project Management / Scrum in the context of software development (well, nothing stops you from deploying pieces of Agile / Scrum in a non-software context – it is based on common sense after all). Small projects, small teams can afford to define a process that exploits the tailwind:

- A small and collocated team means more direct interaction among team members and lesser management overheads in formalizing project communication (e.g., project status reporting, team meetings, etc.). This reduces the time it takes to collate, transmit and share important project information and also decreases the possibility of information distortion or confusion. A small team means there is high signal to noise ratio in team communications, is also leads to a better utilization of time spent in transmissing, receiving or digesting communication. Further, to schedule any event, one can always convene impromptu meetings around a whiteboard or around the coffee table without worrying about people’s already double-booked calendars or finding a place large enough to fit the team for the next meeting, and so on.

- Having a group of experts means there is low(er) need for managerial supervision and people are generally ‘hand-picked’ for their knowledge, skills and abilities that could typically be ‘mutually exclusive, collectively exhaustive’. This ensures tight interdepency and very high mutual respect among team members. There is lesser ‘competition’ among team members and everyone knows that “united we stand, divided we fall” which fosters teambuilding.

- For a small project, a large swing in any of the project constraints (time, cost, scope) could seriously and irretrievably impact the project in a downward spiral. If the work is new to the team, it could spell bigger trouble, especially if there is no way to do mid-course corrections. Executing projects in an iterative fashion helps shorten the feedback loop and give a chance to make necessary corrections to improve its ability to stay on-course and eventually hit the target. Additionally, if there is a customer involvement on these short iterations, the quality and value of these feedbacks could improve substantially lest any decisions are made that are hard to change if required.

However, if your project is anything more than a handful of people, takes more than a few months and entails issues like external dependencies with multiple vendors and ISVs (Independent Software Vendors), substantial technical and managerial risks, subcontracting / co-development, etc., you probably might improve chances of success using a formal project management methodology like PMBoK or PRINCE2 than without it. Agilists will argue and disagree with me that Agile / Scrum is not suited for large projects, but if you are new to Agile as well as to large projects, you might want to consider all options and associated risks – don’t believe in what worked for others, it might or might not work for you (remember the golden rule – we are all different), and your company might have a different set of constraints and tolerance to performance.

The size, complexity, criticality, and risk profile of a project, and organizational appetite for project risk and uncertainty, and organizational culture would generally determine the level and need of management control required, and hence one must always right-size the project management methodology based on the context. Both, PMBoK / PRINCE2 and Agile methods evolved in response to challenges seen in executing projects successfully. While PMBoK / PRINCE2 took the approach that projects most often failed due to lack right levels of management oversight, planning, execution and control; Agillists felt the key reason was the fundamental nature of software being a ‘wicked problem‘ that just could not be managed using an obsolete waterfall model of developing software - it needed a better way to develop software in short iterations with very close-knit self-managed teams.

Without getting my loyalties needlessly divided betwen the two of these approaches, I believe there are merits in both the thoughts. I refuse to believe that any non-trivial project can be managed by piecemeal iterations that give no commitment whatsoever on the overall project performance, nor give any method to assess if the overall project is indeed on the right track (so, even if first few iterations are achieving the desired ‘veolcity’, what is the guarantee that subsequent iterations will also move at the same pace?). On the other hand, doing an iterative development is highly intiutive and very effective way to learn from past experiences to plan next steps, especilly on any non-routine project that is full of unknowns and assumptions. To me, these represent ‘mix-and-match’ ideas that one should pick up and apply wherever required, without getting baptized to the school of thought. I find most process wars have taken the disproportionate dimensions of falling just short of religious wars – you have to belong to one of the camps, and must talk evil about the other camp to be seen as a law-abiding corporate citizen of that camp. In life, we borrow ideas around us – our housing society, professional volunteer society we volunteer for, our kids playground, gardening, home improvement, nature, science, religion, other cultures…without necessarily converting to another faith or religion or society just because we like an idea that we want to borrow. So why should that be required in project management methods ???

I think this process war will be won by pragmatics. Those who take a position on extreme ends of the continuum and insist on always applying a particular style as the panacea might be in for a complete surprise because no two problems were created equal. A prudent approach is to evaluate all options and then decide which is the best response to a problem, as opposed to blindly follow a project management approach ‘religiously’.

Do you follow your project management aproach ‘religiously’ ?

[From my blog Manage Well, http://managewell.net]

In order to build this site into an open clearing house on Project Management related information, I'm putting out an open call:

If you know of *any* great sources on Project Management - books, websites, people, newsletters, magazines, etc - please let me know. I have just activated the Technorati and Del.icio.us aggregators which will be available to all. Information on companies, vendors, tools, books, etc is welcome, but all references should be *relevant* to topics associated with Project Management and should not be sales pitches.

This is a community site, let's get going.