The report provides the results of a survey completed by 596 IT and Business executives with the majority of respondents being IT professionals (476 out of 596 were IT professionals).
The results are interesting. A quick summary of the results is provided below:
75% of respondents admit that their projects are either always or usually “doomed from the start”.
80% of respondents admit that they spend at least half their time on rework.
55% of respondents claim that business objectives of IT projects are clear
23% of respondents state that they are always in agreement when a project is done.
73% of respondents claim that the IT team is successful or very successful in delivering projects that meet the business expectations. Note: “successful” was claimed to be meeting 70% or more of the project goals.
75% of respondents claim that IT is a valued, trusted partner and critical to the company’s success
Interesting stuff. Good to see that last point for sure.
I wanted to take a second for a little discussion on a few topics…
At times, I think that part of the problem with most IT projects is the attitude of the IT team…and this survey seems to highlight that with the fact that 3/4 of respondents believed that projects are doomed from the start. You start a project expecting it to fail, you are going to most likely fail.
Almost 3/4 of respondents claim the IT team is successful in delivering 70% or more in project deliverable. Since when did meeting 70% of a goal mean success? Calling 70% of project goals a success is kind of like saying ‘meh…just do the bare minimum to squeak by’. In school, a 70% is a “C-“….I don’t know many teachers that would be telling a student that they were successful if they finished the year with a “C-” average.
If meeting 70% of a project’s goals is considered a success, then yes…the projects are doomed from the start.
In the world of trading and investing, you learn by failure and you learn by success. There’s so much to know and comprehend as a trader and investor. To succeed, you’ve got to be prepared for failure and you’ve got to focus.
In addition…you’ve got to be prepared to follow the ‘rules’.
There aren’t any rules set in stone. To really be successful, you have to make your own rules. You’ve got to find a system or approach that works for you, your investing / trading time frame and your financial situation.
For example – if you want to live off your trading earnings monthly, you may not want to undertake a long term trend following method. Or – if you only have 15 minutes per day to give to the market, you’d be much better off taking a longer term investing approach and finding / building a system that works for you.
So – these ‘rules’ and your system / approach is important to your success. Without them, you’ll not really have any serious plan for success as a trader / investor.
The same is true for the world of project managers, no?
Without a formal project management ‘method’, how can you really know where you are going, how you will get there and/or when you are done? FYI – I don’t care if your using an ‘old’ waterfall method or a ‘new’ agile method for your projects…you have to have a method. You have to have a ‘system’ for accomplishing your project goals.
This system is full of rules. These rules are set in place for a reason…they help direct the project managers, project team and stakeholders to understand what’s happening, why its happening and where the project is going.
Without these rules you’re pretty much hosed. The project will be off track and you can bet you’ll break one of the time, budget or scope areas within the project. These rules are in place to guide a project manager and team.
Regardless of whether the PM or project team agrees with the rules or the approach, they’re there for a reason. The PM may have an opinion that the plan isn’t correct, but she better not deviate from that plan without first going back to the stakeholders and getting approval to change the plan.
Same goes for the project team…they may have their opinions on how things should be done, but they better not deviate from the agreed upon approach without first circling back to the PM to make sure their new approach doesn’t affect some other team member’s approach or affect the overall project plan.
The same is true in the trading and investing world. As a trader, you have a plan, a system and your rules…and you need to follow them. You may have an opinion about the market, but unless that opinion is worked into your plan with the proper rules for managing risk and entry/exit, you might just get ripped to shreds in the market.
…an opinion is not a position and a position is not an opinion…This is a tough lesson for novice traders to learn. But it is a lesson that must be learned.
There’s a difference between an opinion and an investment / trade. Without applying your system and rules to that opinion, you shouldn’t make a trade. Same is true for projects…without running your opinion through the approach system, you can’t really tell what risk that opinion might introduce into the project.
In the same article, Peter writes:
Do I periodically override my rules? Yes. Do I usually regret overriding rules. Yes again. My trading rules are based on what I know about market behavior, not on how I feel at any given moment….
Battling the emotional pull to override trading rules is the toughest part of my job. There is not even a close second.
It’d be very easy to change this to focus on projects…a project’s plan and stakeholder agreement (i.e., the rules) are based on years of experience and expertise, not on one person’s opinion. One of the toughest things a project manager (and trader) can do is keep their opinions in check and ensure their systems are followed.
Your system (e.g., project plans, procedures and processes, etc) are there for a reason…start working outside that system and you’ll have hell to pay with project failures, cost over-runs and/or scope creep (or…as a trader…monetary losses out the wazzoo).
Now…unlike the photo I used at the start of this post, your opinion does, in fact, matter. Just make sure you run that opinion through your system and processes to ensure that its in line with reality.
As a project manager or trader/investor – your system and rules are your life…follow ’em or fail.
That question: is project management a skill or a technique?
Before continuing, let’s take a few minutes to look at the definition of skill & technique to better understand the distinction between these often mis-used words:
Skill is defined as: an ability that has been acquired by training
Technique is defined as: a practical method or art applied to some particular task.
Are project managers using abilities that they’ve learned from training and/or experience or are they applying procedures & methods to tasks?
I’m pretty sure that the folks at the Project Management Institute and PRINCE2 would argue that Project Management is a skill learned through training and years of experience.
I know a few people who think project management is nothing more than applying best practices to specific tasks to get something done with very little thought to the skill behind that application.
Project management is a discipline that requires real skill, abilities and experience. Sure…you can use project management techniques to get things done, but project management as a whole, is a discipline with a real honest-to-goodness skill set.
What’s your thoughts….is Project Management a skill…or just a set of techniques? Or as Shim wrote…Technique or Discipline?
Update – My original post was titled “A milestone – 4 years old”. Apparently I can’t count 🙂 I started the blog in 2006 so it’s my blog’s THIRD birthday! 🙂
I started this blog on July 14, 2006 with a blog post titled “The Strategic Use of Human Resources“. My first post was an excerpt from a paper I wrote for my MBA program of the same title….not exactly the most exciting stuff in the world but it wasn’t bad.
When I started this blog, I didn’t have a plan. I still really don’t. Many people tell me to pick a topic and focus…perhaps they are right. But that isn’t me. Sure, I can focus….but why should I be forced to do so on my own blog? I see this blog as a place to share my thoughts and help people understand who I am. I write about what I want but try to remain within the Technology, Strategy, People & Projects arena.
I have found a few topics that are of great interest to me. Specifically the intersection of marketing & technology and how enterprise 2.0 (and 3.0) is changing and will change business in the future. I’ve also started off The New CIO series where I’m planning on taking a look at the role of the IT group and CIO from a different perspective. So far, I’ve written 3 The New CIO articles and have plans to write one article per week (released every Thursday). The published articles so far are:
So I’ve finished up 3 years and I’m entering the fourth year and I’m going strong. I passed the 400 posts mark in June (~2 posts per week) and 1000 comments that same month. I also bumped over 1000 RSS subscribers sometime in 2009…but never really saw when it happened. Twitter and friendfeed have helped grow traffic but at the end of the day, this blog isn’t about traffic…its about delivering good content to those that like to read it.
The full title of the book is “Reinventing Project Management: The Diamond Approach to Successful Growth & Innovation” and, as the title suggests, it covers an approach that the authors call the “Diamond Approach” to determining risks and benefits of a project. The diamond is comprised of the following items:
I could spend some time discussing the diamond approach but wouldn’t do it justice and I don’t think that it is the most important take-away from this book. The major take-away for me is that this book says what I’ve been saying for years: Project Management requires a more flexible approach than current methodologies allow.
On page 206 the authors list the “Main Lessons” from the book…lessons that are pure gold for project managers and organizations. I’ve listed a few of the ones that I thought were ‘gold’ and also provide commentary below.
Project Management isn’t about delivering a project on time, on budget and within scope; its about serving a customer and delivering results.
How true. Many PM’s are so focused on staying within the ‘Iron Triangle’ of scope, time and budget that they lose track of the business value that they are (or should be) delivering to their clients.
To succeed in projects you must use an adaptive project management approach, adapting your project management style to the environment, the goal and the project task.
The rigidity of modern PM methodologies causes many problems for those PM’s that try to adhere to them in a strict manner. To lead a project to success, PM’s must be able to think on their feet and adapt the PM methodologies to the ever-changing environment.
Overall, this book is definitely worth the time it takes you to read.
Organization Alignment seems like one of those ‘touchy feely’ things that most technical folks would rather not discuss but it’s actually quite relevant to success in todays technology and project driven organizations.
Organizational alignment is the practice of aligning an organization’s strategy and culture. In other words, organizational alignment helps to ensure that ‘what gets done’ is in line with ‘how things get done’ and vice versa. For a more detailed description of organizational alignment, take a look at the article on Organizational Alignment on Vanguard Consulting’s website.
As mentioned, Organizational Alignment is the act (or art?) of aligning strategy and culture. The field of strategic planning and organizational strategy is a very well researched and fairly well covered in academia (and blogosphere) so I won’t go into the ‘strategy’ aspect but I will cover the ‘culture’ side here.What does organizational alignment have to do with project success? In my opinion, everything.
For a project to be successful, an organization must have its strategic goals aligned with its cultural values…and projects must also be aligned with the organizations’ culture and strategy. Consider the following brief example (paraphrased from Vanguard Consulting’s website):
Assume that the goal of your organization is to create a flexible service delivery model to allow you to be flexible for your clients. You’d want to make sure that the organization is aligned to meet these goals by having flexibility as a core value. You wouldn’t want to implement a ‘command and control’ structure that requires everyone to get approval before acting. The command and control structure would completely counteract the stated goal of flexibility for your clients.
The cultural aspect of organizational alignment covers ‘how things get done’ (while the strategic aspect covers ‘what gets done’). The ‘how’ covers the values, behaviors and processes for getting things done, which are things that can be addressed across the organization using various methods, such as the implementation of a Project Management Office (PMO).
Many organizations have implemented PMO’s to standardize project management methodologies, align projects with corporate strategy and act as a central point of management for all things projects. The majority of these PMO’s usually don’t address the values and behaviors across the organization. In fact, most definitions of a PMO only describe the use of a PMO to standardize project processes and align projects with strategy but values are usually overlooked.
A PMO is a good thing for most organizations but its doesn’t go far enough to ensure alignment. Standardizing project methodologies can be a good thing but standardization doesn’t go far enough to address the issues of values and behaviors. The PMO, by definition, isn’t setup to address values and behaviors but could easily be converted into an office to help align values, behaviors and process and perhaps it could be renamed the ‘Project & Alignment Office’ (PAO).
So….after all of that (and my creating the PAO!), how do we ensure project success by organizational alignment? We don’t…you can never ‘ensure success’…but we can help set projects on the path towards success by working to align the ‘how’ with the ‘what’ and the ‘why’.
Look for more to come on organizational alignment and projects…and maybe even more on the newly created PAO 🙂