Project Based Organizations

I cant think of a company making improvements without a projected organization, even if it is not a formal one. Organizing and adopting a proper methodology will help in reducing risks and increasing probability of success in project deliverables. Any strategy derived from planning can only be achieved by a set of well organized projects.

Best regards,

Like many management fads, project oriented organizations has some basis in truth with a whole bunch of looking for the golden bullet dumped in.

Most organizations consist of three seperate structures. The first is strategic, the second is operational and the third is core.

Strategic structures consist of those structures which are project oriented in nature. That is everything they do is one off. Why call them strategic? Because most strategic activities are project oriented. Even if an organization does nothing else project oriented, change (i.e. strategic implementations) are projects. However, IS is probably the most well known project focused group, closely followed by marketing and HR for those elements not strictly part of a strategic team. You'll notice, however, that those groups tend to be the most affected by and involved in strategic activities.

The second group is operational. These are not project oriented. Instead they are on going and routine. Or have become so. Examples include Accounting, janitorial, and telephones operators.

Core are those groups which are directly associated with the delivery of the product. Why seperate them like this? Because they can go either way. Some products (such as automobiles) are project oriented (each is unique and built to order). Other products are delivered using a process method - retail for example. The trick is to know which parts are project oriented and which aren't.

The point of this is that all organizations have projects. All organizations can benefit from project/portfolio management knowledge. And all organizations can benefit from a project/portfolio based approach. Regardless of how the core is most effectively structured. A basic understanding of the correct approach is mandatory (but often missing) in all levels of management because all levels will participate in projects.

The second point is that no organization needs or should be totally project focused. All organizations have groups which are focused on doing the same things the same way every day.

Finally, the smart organization is the one that knows what focus to apply where, especially in its core since that can flip to either side.

Does that help any?

Glen Ford, PMP
Can Da Software
Project Management & Process Improvement

I managed a development group that was overfocused on projects, and I had to help them relearn how to do process work, i.e., work that has to be done on a repetitive basis every day, week, whatever. The killer was configuration and build, which is not project-oriented but is essential to project success.

Project work and process work have different approaches and emotional demands. You can be an excellent project-oriented service organization, but getting the invoices out every month cannot be a project. It's just exhausting to live that way.

There is a sweet spot between the two extremes. Finding it is an organizational engineering task.

Since 2002, our corp IT has used PM methodolgy. The CIO (new at the time) said it would boost efficiencies, get products out on time, and help justify the hireing of new employees.

In 4 years, the highest growth position in IT has been the Project Manager's position. There are now 9 in a department of 28. The amount of paper work and documentation has grown to such a degree that most net admins and developers have quit. I have to admit, the CEO has been happy with the improved level of service in many areas, as well as improvement in budgets, but the price has been high. The IT dept has seen a turnover rate of 70% in 4 years, and there is definitly a problem between the Project Managers and the "worker bees". The hiring of the new project managers (avr salary of 65,000) has been at the expense of the developers and net admins. Promotions go to the managers and not the techies. Currently, IT has hired 5 contractors to administer the enterprise network, while the CIO hires new people. Contractors usually do not do projects (some cost as much as 100/hour), and the project managers do not have the tech skills to get things done. So, they have 9 Proj managers with nothing to manage.

Regardless of the type of business, there is a great deal to be gained in using Project Management standards.

Think of PM in the construction industry - we have been building structures for thousands of years. There are specific inspection points, strong subject matter experts and explicitly detailed plans. At the end of the project we have a building with the right number of toilets and the right number of floors on the right piece of land and according to the Standish Group 96% are successful.

In comparison, of IT or software projects only 9% are considered successful. Why? We have only been building software for 30 or so years. In construction we would never allow the plumber to run the electrical lines or skip an inspection because testing was cut short to meet the deadline but it happens day-in-day-out in software.

When some people hear Project Management or PMO they think beauracracy, they think slow down... but clearly in comparison faster is not more successful.

When you think about how much an organization can waste on projects that do not deliver expected returns it should be an easy win but executives want IT to be fast. It is a classic case of not managing expectations.

Most DoD contractors use project management and direct costing accounting methods. It's been SOP since WWII.

Can an IT department also be project based? In the DoD world, the IT department would be considered an indirect cost [facilities cost/overhead]to a job unless the project specifically included IT as a cost [such as equipment, applications whatnot specifically needed for the project]. The downside for IT is that typically the if the govt pays for it, the govt owns it and therefore IT equipment needed for the project becomes govt property [with all the inventory control, accounting for, tracking of the equipment]. When the project is over, the govt takes possession of or the contractor provides disposition of govt property [such as sale of the items which the govt gets the $$ for].

In the Corporate world, accounting for [both monetarily and physically] IT on a project by project basis can become a full time job itself [depending upon the size of the company]. On the other hand, having an II person dedicated to a project removes the IT labor costs from overhead to direct cost [thereby decreasing overhead costs as a percent of direct costs]. This can decrease the price to customers [overhead can add an amount to the price that is greater than the actual cost].

Hi j.lupo- I apologise that I haven't responded before now- busy enough that a considered reply wasn't feasible.

Keep in mind two things- I am not familiar with your citation and I am a project manager- I focus on projects.

With that said...

I have worked in and around technology for around 20 years. In that time I have watched business hand everything over to the IT staff and I have watched them take it back.

In order to do business effectively, you must concentrate on what the core business is. Do you manufacture something? Your concentration must be there. Do you fly planes? There's your focus.

The IT functions of the company MUST support the primary business goal, or shortly your customers will leave you in numbers. The guy that wants to fly on your airline doesn't care about how many servers it takes to keep the reservation system going. He wants to fly from NY to LA and he wants to do it on HIS timeline. He wants his reservation process to be easy, he wants his check-in to be easy. He knows that he has to put up with the security gates, the other travellers, the screaming kids. He wants to take off safely and he wants to land safely. He doesn't care if you have upgraded to the new Windows software or if you are using a Westinghouse terminal or if you have carrier pigeons taking messages. He wants what he wants.

From the business perspective, your primary purpose is to get him where he wants to go. As few hassles as possible.

From an IT perspective, a number of projects might be suggested to facilitate the business objective depending on existing architecture and business process. At the end of the day, the business need MUST define the IT project.

Project based business fails miserably when projects are not developed with the key business driver at the forefront. Projects for the sake of IT need to be able to justify their existance from a business perspective.

That said...

Business must learn that IT is not the "All Powerful OZ". We can do what technology tells us we can. We MUST build scalable strategic systems to benefit business. And business must learn that we cannot build what we do not know. Business has a responsibility to provide requirements that can be managed to. IT needs to have a position in which we can ask the questions of, not only business, but the end users. IT can be extremely flexible if given the opportunity. But business needs to understand that we can do only so much. I can give you what you tell me you want. I am not a mind reader so cannot see what you envision.

As a PM, I have often kept a Magic 8 Ball on my desk next to a pair of dice and a crystal ball. I refer to them as my "estimation tool-kit". It works like this- Business comes to me and tells me that it wants to deploy a particular technology by a defined time. I do the high end analysis and tell them that while it can be done, these sub-projects must be done first. Business tells me to give them an estimate on $$$ or completion time. Since the requirement is still vague and the under-pinnings don't yet exist, any answer from the Magic 8 Ball is as good as any other. Then I can tell them why this is so.

Business needs to understnad that they are not IT and therefore cannont dictate HOW we do a project. They can define our deliverables and give us the constraints. It is OUR job to provide the detailed design that will path them to their goals and OUR job to deploy those designs once they have been signed off.

I could keep going but I think that you get my points. IT is an operational function. Business must focus on their core business to be successful. Business needs to trust that IT will do the right thing.

Projects do not run business. Business does.

as well. CSC was where I learned about DoD work contracts and the leasing of equipment. In the infrastructure area though, CSC had their own equipment, in other areas it was all Government and believe me there was a big difference in the equipment.

CSC on some of its contracts was melded pretty closely with the DoD officers, meaning military folks in charge. At any rate, I certainly have a lot of new information to digest. Thanks for the input.

and I am still learning to make my thoughts as coherent as yours. It is funny, I may not use the same words as you, but I have been saying the same things within my research. Now I had to take several steps backward to try and conduct the research objectively.

People who work in our industry see the problem, we know it exists, we all want solutions, but we never get any. That is why I think it is essential that we need to start developing true partnerships with the business and key business leaders need to be involved (before project initiation) with key IT leaders (not necessarily the CEO and CIO, depends on size of company(s)). If they partner and establish the necessary guidelines for whatever IT needs to deliver, then many of the problems that you, and others in this discussion, and I see, can be solved.

My schedule is so busy, I forgot what my bed looks like, no idea about the couch either. My current project is a perfect example of what NOT to do, but I have not authority in any direction to change things. So, all I can do is my best with the team I have. When it fails (and it will) at least as I go out the door, I can say "I told you so".

Anyway, my interest and passion in this topic is because I want to find the right way to influence decision makers on these issues and hopefully at least start dialog to improve our results.

I once read a little ditty someone wrote (I don't have the full thing anymore) but it ends with:
We gave them what they asked for and they said
yes this is what we asked for but it isn't
what we want.

I have found through my research that business is more intuitive and IT is more specific. I call it the cooking by feel (experience) or by recipe (algorithm). Business knows what it needs to accomplish but can't communicate it in logical, repeatable steps and IT can only deliver logical, repeatable steps.

Do you know how many times I joke with people about the ESP circuits were recalled and the technology is not ready for deployment? I hear all the time from my business users - well it should know what I meant it to do.

As some of you may already know and have participated I am doing Real research on a small piece of this topic as partial completion of my doctorate. I also will be publishing the results, I hope, here on TR and get them published in professional zines.

At any rate, for those that have not participated yet or did not know about the research, please consider taking the very quick survey. There is a discussion in Miscellaneous group called Real Research on IT Projects by me j.lupo. You can find out more in that discussion about the research if you want, or you can go to the website I had setup: www.jrlupo.net.

The first page is just some instructions/information and then the 2nd is the actual survey.

Thanks in advance, I appreciate the responses. With enough I can finish my research this year.

of some of the issues, but money plays a big part in the decisions. There are a lot of companies that used to keep IT departments to do everything they needed and ordered from Vendors when they weren't creating customized systesm. The problem is our economy changed and the idea to downsize and reduce costs became the norm. So, these IT departments were no longer needed.

Budgets controlled the decisions more than skills needed for the business. In construction there is a more direct one for one relationship between the business and the people you need to get the job done. In IT, the lines are not as clear cut and there is a great deal of overlap. If you don't know what you are doing and define your project well enough, budgets end up overrun or the project ends up cancelled.

of some of the issues, but money plays a big part in the decisions. There are a lot of companies that used to keep IT departments to do everything they needed and ordered from Vendors when they weren't creating customized systesm. The problem is our economy changed and the idea to downsize and reduce costs became the norm. So, these IT departments were no longer needed.

Budgets controlled the decisions more than skills needed for the business. In construction there is a more direct one for one relationship between the business and the people you need to get the job done. In IT, the lines are not as clear cut and there is a great deal of overlap. If you don't know what you are doing and define your project well enough, budgets end up overrun or the project ends up cancelled.