I’ve got used to differentiating between operational work (“standing organization”, “business as usual”) and projects. But projects in mainstream business seem to be a fairly new concept (I’m not talking about construction work here). Yet, you find them everywhere – IT projects, process improvement projects, organizational projects. Projects seem to be another method to make better use of a company’s human resources. Or so it seems… If a person has “operational responsibilities” you can still put him or her on a project. If it’s a project function, unless you are doing time-tracking and Business Resource Management, the difference between a resource’s 50% or 300% on projects is just a matter of… numbers.
For many of us, projects became a synonym of change. These days, one starts to believe that before this concept was rediscovered in the western economy, progress was virtually non-existent.
I have the impression that projects aren’t so popular in Japan. The traditional approach, Kaizen, is more about small, continual improvements rather than bursts resulting from additional, project effort. Why is that? Why does Toyota strive to create the best basis for small, numerous improvements, to make it as easy as possible for everyone, instead of spending zillions on projects? Do we miss something here?
“Integrity comprises perceived consistency of actions, values, methods, measures and principles. (…) A value system may evolve over time…”
Source: http://en.wikipedia.org/wiki/Integrity
I believe that integrity is about balance. About small improvements in a generally strong, consistent system.
I cannot provide a certain answer to the question posed in the title. But I am very much aware where projects came from and where they are indisposable (construction industry). I’m not sure their grounds are equally solid where I see them now.
I like your blog! Thank you for your comment on mine (not sure how you found me, but I’m glad you did – it’s great to come across like-minded people.)This is a really interesting posting to me, especially because I was formerly a project manager in a service company and have been contemplating the legitimacy of project management in the service industry ever since.In a creative service industry, I witnessed how project management lends itself to a “tunnel vision” approach to work, and I imagine this is the case in other industries as well.Ultimately, a “process manager” might be a more legitimate role in a company that manages services from the outside-in. Project managers within some environments spend ALL of their time making up for the lack of process, so process never gets properly addressed.Project managers MIGHT be needed to interface with clients if the resources don’t want to. However, sometimes there is a lot of overlap with the Account Manager on this end, so this actually may not be legitimate. An arguable role is setting a schedule, but I found that these task-oriented schedules that had so much flux due to client changes and were so isolated from one aother that they could never be counted on to be consistent.Another role is often to babysit the resources according to the task-oriented schedules and make sure people are actually working on the things they are supposed to be working on.Finally, I observed that an incredibly time-consuming role as a PM was passing work from one person to another. A good project manager is supposed to be able to communicate information effectively, but again – if process is not given proper attention, there may be inherent process problems make it nearly impossible for them to do so. In this circumstance, project managers could actually impede the process by not giving the resources or clients all of the information they need.In the kind of environment I am describing where process is neglected, the PM role is necessary, but not necessarily value-added. It’s possible the PM role could potentially become obsolete if the right questions were focused on: What processes could we automate through visual signals? How can we best isolate commonalities among projects and standardize them? How can we best prepare for and handle variability? How can we prioritize effectively shop-wide, versus always having projects in competition with each other? How can we better understand the client’s objectives and decrease the need for back-and-forth? What can we do to maximize the use of our resources overall so that we increase quality and decrease our overall turn-around times?Obviously, you’ve stirred up a lot of thoughts, but I think these kinds of things are great to think about!Best to you in 2009,-Jackie
Thank you for a valuable comment! To give you more information on how I reached your blog (I find the whole social networking thing quite immense). I suppose I added a favorite to one of @toddbrink’s tweets-links. And then… I read your post, liked it a lot, added a comment and subscribed to your blog’s RSS feed. That’s it :-)Our thoughts on this one seem aligned. The whole projects’ thing reminds me of an old canoe race joke:http://personalmba.com/friday-joke-the-canoe-race/Have you seen that one? :-)Interfaces with clients seem to require a project approach (implementations). But these cases are often closer to processes than projects as such. Of course, many of them have a big deal of uniqueness. But then, sometimes what’s implemented is a standard product (tweaked or not). And if it’s completely new, then usually it’s what’s the supplier’s entire business model is about. Marketing, software development etc. If I were an owner of such a business, I would strive to put in place as much standardization as possible, to minimize unnecessary risks, to create a safer environment for employees, to be more consistent towards the clients. Many a case, we try to do it by a standardized PM methodology, but wouldn’t it be better to look at it from a process perspective?Thank you once again, Jackie! Have a great 2009 and beyond!-Lech
For the record, the above-mentioned joke is partly about Americans, but it’s a general issue and many of us make such mistakes – in business or life in general.L.
[…] Will Projects Cease to Exist? […]