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.

Image Credit: 110..365 | The End? By Katkamin on flickr

I’ve written a few words on the topic of Strategy, Tactics and Hope in the past and have even talked about minding the gap between strategy and tactics.

Most people and organizations understand – at least in theory – that they need a strategic plan to be successful. And…by strategic plan, I mean something that drives the direction of the organization….it could be a 500 page document or it could be a short half-page plan.

Many people / organizations take this strategic planning process very seriously. Teams are formed. Meetings are held. Numbers are crunched…and document written.

The outcome of a strategic planning process is the final plan (hopefully). Everyone signs off on the plan. Everyone looks at that plan as the saving grace of the organization.

Project teams are built. Implementation plans are developed. Everyone’s excited.

Then…nothing happens.

And…nothing continues to happen.

Why?

Various reasons of course. Granted…there are many organizations that build a strategic plan and do what needs to be done to make that plan a reality…but there are also many that don’t.

One common cause of failure that I’ve noticed in organizations is a simple one…nobody stops to really consider the tactical approach to the strategic plan.

Those same organizations that have eschewed hope as a strategy embrace it as a tactic. They ‘hope’ they have the right people in place. They ‘hope’ everyone knows their role and their responsibility in make the strategic plan a reality.

Now…no organization actually uses the word “hope” in their planning, but it becomes clear when the strategic plan is reviewed and compared to the implementation plan.

Granted…in my posted titled Strategy, Tactics and Hope, I used the word ‘hope’…but I meant it in a different way (really..I did!)

In that article, ‘hope’ is from the employees side…they have to believe that they can achieve the goals in the strategic plan.

The hope that I’m talking about here is the replacement of the planning and thinking process with a “hoping” process.

These organizations build elaborate strategic plans but fail to build on elaborate tactical plans to reach their objectives and just hope that things are in place to meet their goals.

Don’t fall into the trap of hoping…hope isn’t a strategy….and its not a tactic either.

Image Credit: …Hope…By ĐāżŦ {bad contact, no biscuit} on flickr

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.

Two of my favorite traders – Ron Roll (on twitter as gtotoy) and Peter Brandt (on twitter as PeterLBrandt) – shared some excellent insight recently about their approach to trading.

Ron shared the following insight on twitter:

[blackbirdpie url="https://twitter.com/#!/gtotoy/status/103192868109299712"]

On a similar note,  in a post titled When does a victory feels like defeat?, Peter writes:

…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.

Emphasis mine.

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.

Image Credit: opinion By the|G|™ on flickr

Information technology (IT) focus is shifting from classical projects to agile services.

Here’s why.

Reason 1: Much of IT defies project definition

A classical project has a predetermined start, end, and result. When done, the result goes into “maintenance mode”, and you jump to the next project.

But what if something never has a “maintenance mode”?

For example, the web is never done. A university’s web site must be exciting and work quite well; the key audiences are technologically progressive prospective and current students. What university wants technophobic students? Relevant university sites must keep up with rapidly evolving consumer technologies.

A university’s web site is a good example of an agile service: an adaptive mix of agile applications and expertise. These are where a lot of IT’s attention is going.

Agile services don’t end. They are not classical projects.

Reason 2: Small projects don’t matter much

Isn’t a service just a lot of mini-projects? And isn’t the last trend to make projects smaller?

Neither matters much. Small projects are really large tasks or iterations in an agile project.

By themselves, small projects don’t tell the value of IT. Agile services do.

Reason 3: Virtualization and clouding

The largest classical IT projects are implementations. Virtualization and especially clouding make it easier to create new things, sometimes almost erasing implementation projects.

Taking away implementation focus shifts attention to maximizing value of existing investments. Again, emphasizing agile services at the cost of classical projects.

Reason 4: Agile is where it’s at

Classical projects use waterfall, a prescriptive method from the manufacturing and construction industries. It’s from a time when the pace was steady, change was resisted, and top down was how it happened.

Relevant IT is the opposite: fast-paced, adaptive, and responsive. That’s why agile project management is natural for IT: it encourages adaption, continual reassessment, early problem discovery, and faster completion.

I’m not the only one seeing this. A proxy is Atlassian JIRA versus Microsoft Project Server. JIRA is for agile, whereas Project Server is for waterfall. Look at their Google search trends (source):

But this isn’t just about improving how projects are done. Agile does something that waterfall can’t: manage services.

Paraphrasing Men In Black II, “Waterfall projects: old and busted. Agile services: new hotness.”

Do classical projects belong in IT?

To be clear, classical projects still have a place in relevant IT. Really complex projects aren’t entirely going away, and some may need waterfall. Same goes for projects with well-understood paths and vanilla outcomes.

However, “well-understood” and “vanilla” are starting to be outsourced, such as email, web systems, ERP systems, and more. If not outsourced, they may be heartbeat functions, increasingly undifferentiated from plant operations. Or their business value is not intrinsic; the value is in what others—users, innovators, developers—can wring from them.

Agile services are the future of IT. It’s how we work, it’s how we provide business value, and it’s how we communicate what we do.

Image Credit: Project Management Lifecycle By Ivan Walsh on flickr

If you don’t know who ISITE Design is, you should…especially if you are in the digital marketing space. Those guys are top notch. I tried to hire them many times when I was working at the Boy Scouts but could never get the projects funded (might just be why I’m not there anymore).

Note: I tend to use “CMS” to mean “Web CMS” or “WCMS” – in this article these terms/acronyms are interchangeable to match what David originally used it in his post.

In Avoiding the CMS Death Spiral, David writes a nice piece that anyone looking at choosing a Content Management System should read.  In the article, David offers up a few pieces of advice, with one being:

Realize too that if you invest in a CMS, you’re now in the software business – whether you like it or not. A CMS project is never “done”. Staff accordingly for post-launch maintenance and support, or be prepared to pay an agency to maintain the platform for you (to one degree or another).

A CMS project takes on a life of its own, much like any other software project. That said, most organizations undertaking a Content Management System project fail to understand that real underlying issues that they will face during and after the project. Most people think a CMS project is as simple as selecting, paying for and implementing a CMS….but it isn’t.

A CMS project is everlasting.  There will always be ‘something else’ to do.  There will always be a new feature or some functionality that will be needed for some new web feature or function.

Done never shows up on a CMS project.  Done never is.

Of course…there are times of ‘done’ according to a project plan.  The goal of a project can be reached.  There is a point when a CMS is ‘implemented’. But…there will always be changes  and there will always be new items to add.

That’s what organizations need to understand. Many think a Content Management System is something you buy and install and use.  But, I’ve never found that to be the case.  There’s always something more to be done.

So…if you are currently looking at implementing a Web Content Management System, think long and hard about how you are staffed today and how you will be staffed in the future.  Don’t make the mistake a former client made in thinking that after the purchase and implementation of a CMS, he could reduce headcount. In fact – he needed to increase headcount or at least move headcount around to ensure proper staffing.  That particular project was never staffed properly for the long term from the IT group’s side.

I’ll leave you with part of my comment on David’s post. I wrote  (I noticed a typo in my original comment – I’ve left it here for completeness – but should be buy):

One of the biggest mistakes I’ve seen with CMS projects is the failure to staff. Most clients but [sic] a CMS platform, pay a vendor to implement it and then expect ‘done’ to arrive one day.

That day never shows up because there are always constant changes coming. Always new features and functionality for CMS driven websites. Done never arrives so clients always feel like they are spending way too much to ‘implement’ their CMS…when in reality they are just seeing the reality of the software business. Done never is.

Image Credit: Never By Olivier H on flickr

According to the description on PMI’s webpage about their new Agile certification, the new certificate will:

validate a practitioner’s ability to understand Agile principles and concepts. The practitioner can then select “Agile” from their “toolbox” of project management approaches based on the needs and demands of a specific project.

Will I go after this agile cert? I doubt it.  I’m not doing much in realm of formal project management these days. Plus…I’m not a big believer in certificates, even though I earned my PMP in 2006.

I’m not focused on pure project management in my consulting so it may not be worth the effort…but I’m thinking it might be interesting to see what topics the PMI feels are important in an agile project and how I can ‘select’ Agile from my PM toolbox when needed.

That said, don’t let me discourage you from going after it…jump over to the PMI Agile Certification page to learn how you can be a part of the pilot.

Image Credit: 1965 QANTAS Certificate By Serendigity on flickr

Go read it.

In the article, Neil argues that IT needs to focus on projects that focus on The Customer.   He writes:

Too often we in the IT department are seen as being out of touch by other people within the business and make strange decisions where we do IT for the sake of IT are often at the heart of it. This doesn’t mean that you don’t experiment to learn if something has value, but does everybody really need the latest iPad to figure out if it has a business benefit? Technology is great but it is an enabler to make lives better for Customers and profits for the business. We need to and must want to use our technology, process and people skills to make better products and generate wealth for our investors.

Emphasis is Neal’s…but I would have emphasized the same things

I wrote a comment on the post that I thought worth sharing and expanding on here.  A snippet of what I wrote is:

At a previous client of mine, I helped them come up with the following three questions for deciding whether a project gets the green light (or the red light if its already started).

1.) Is the project needed for base infrastructure? Note: These are the ‘un-sexy’ projects that must be done to ‘keep the lights on’.

2.) Does the project help us meet one of our strategic goals? How?

3.) Does the project deliver real, measurable, value to the customer? How?

Using those three questions helped my client cut back on a lot of pet projects and non-essential projects. In fact, those three questions led to the hiring of more IT staff because there was more budget available for the necessary projects.

My three questions above are simple and simplistic by design.

Too many times we tend to get wrapped around complex systems and processes, especially when making decisions about what project to fund. Too many times politics comes into play in those decisions as well.

The above three questions worked (and still work) for that client because they understood the value of simple rules and everyone in the organization (at the highest and lowest levels) believed that these rules were worth following.

I’ve seen many projects get funded because they were the pet project of someone on the leadership team…but the project had zero affect on the ability of the business to deliver value, revenue and profit.

With these three simple questions, and the fortitude to follow them, this client was able to cut back on those pet projects and focus strictly on those that were absolutely critical to the company and its clients.

By focusing more on the critical projects, a side benefit was realized for the IT group – the IT budget started to grow instead of shrink as the business realized that the money spent (wasted) on pet projects could be better spent on improving IT capabilities.  Needless to say…the CIO was happy. He was able to increase staff and implement training programs again…something he hadn’t done in many years.

All because they started asking three simple questions.

Photo credit: Art & Blue Sky By Phil Roeder on flickr

Are you ready to accept failure?  Can you live with yourself if you don’t succeed?

When I was growing up, winning was a big thing.  You won or lost. You won at sports.  You succeeded at school.  Or you didn’t.  There wasn’t anything good about losing…no ‘participation’ trophies…no recognition for losing.

Succeeding and winning was everything.

Everyone fails though.   Nobody is perfect.  Nobody succeeds at every thing they do. With success comes failure. When one person succeeds, someone else is most likely to fail.  That’s not a bad thing though…failure is acceptable if you learn from that experience, right?

Take an example from my new found interest….the world of trading & investing. In the investment world, nobody succeeds all the time.  Heck…most traders are happy if they have 50% win ratio (I’m currently at a 53% win ratio…and I’m ecstatic about that) The key to succeeding long term when you ‘only’ win half your attempts is to ensure you manage your risk appropriately. Peter Lynch, that icon of the investing world, sums up the idea of success / failure in the investing world with:

In this business if you’re good, you’re right six times out of ten. You’re never going to be right nine times out of ten. (HT @Fibline for the quote)

Failure is perfectly acceptable, if you’ve approached that failure correctly and learn from your failure.

Are you allowing yourself to be right six times out of ten?  Are you happy with a 50% win ratio?

How about a having win rate of 5% (1 win out of 20 attempts)?  Would that you make you happy…or angry? Most people would absolutely hate a 5% win rate.

But…some folks can accept that rate and move on.  They learn from their successes and failures.

Take OfficeMax as an example. Scott Brinker recently shared a story about OfficeMax’s digital marketing efforts in a post titled Experimental Marketing: 1 out of 20 ain’t bad.  OfficeMax had 1 successful website (their “Elf Yourself” website) out of 20 attempts.  They built 20 different websites, each with a reason behind it and expectation that it would work.

But…out of those 20, only 1 of them – the Elf Yourself site – succeeded.  The remaining 19 were quietly turned off.

Would a 5% win rate be OK with you? Would it be OK with your company?

Would you or your company ever allow a project to kick off that had a 1 in 20 chance of succeeding?  Probably not…but what if you kicked off 20 projects, each with compelling business cases, and only 1 succeeded?  Would you take the time to understand what worked and what didn’t in those 20 projects or would you fire the people in charge of those projects?

Success is wonderful.  Failure is just as wonderful…if you learn from it.

Now…in the trading world, you wouldn’t really want a 5% win rate…you’d quickly run out of money.  In the world of Marketing, IT and Technology…a 5% win rate isn’t ideal either..but sometimes you’ve got to have the guts to make a decision that might just lead to a low success rate on projects…and you might just learn a great deal about how to get better the next time.

Today’s IT project success rate is hovering around 30 to 35 % depending on what study you read.  Are organizations & IT groups learning from the failures of those projects that aren’t succeeding?  In my experience, no….those failed projects are written off and never looked at again.

So…are you prepared for failure?  Ready to accept it and learn from it?  If you want to succeed more in the future…you should be.

Image Credit: “Success 02 by By PaDumBumPsh” found on flickr. Make sure you jump over and read the small print…It’ll make you giggle…at least it made me

dollar sign $ By Leo Reynolds on flickr

I’ve recently moved back into the world of trading stocks and options.  Most of what I’m doing is small stuff but I’m enjoying it and making some money.

Some quick history – me and trading/investing

In the past, I’d been into investing quite heavily with the ‘buy and hold’ approach.  Find a company with good fundamentals and buy it at a good price.  Then hold it and wait for it to go up.

Not a bad long-term approach. I still have some core holdings that are long-term but I never just buy to hold any longer…I buy with a plan in mind. I know when I’ll sell. I know how much I’m willing to loose and how much I’m willing to earn from the trade.

Today, most of my investments are short trades that i hold for less than a week. Many are held overnight for quick in-and-out trades (call swing trades in the trading world). I do some daytrading (buy/sell in same day) but not a lot since I don’t have enough capital in one account to get past the daytrading rules.

Project Management & Trading/Investing?

So…how has project management helped me to be a better trader?

Simple…as a project manager, you focus on three things: Budget, Timeline and Scope

To be successful managing projects, you’ve got to plan well, spend well and execute well. You’ve got to know what you want to do, how much money you have to do it and then execute properly to accomplish the goal(s).

The same is true for trading.

To be a successful trader, you’ve got to plan well, spend well and execute well.  Just like managing projects, you’ve got to know what you want to do, how much money you have to do it and then execute properly to accomplish the goal(s).

In addition, just like being a good PM, you’ve got to know how to manage risk.  Same is true for traders….risk management is key to a long trading career.

There’s one major difference between trading and project management though…..and its a big one:

Trading uses your money….project management uses your bosses money.

It’s usually easier to spend someone else’s money:)

If you mess up on a project, someone can always allocate more money to the project to cover you…you mess up a trade, there’s nobody there to help….that’s where your budget and risk management come into play.  Put too much into a bad trade and you blow up your account.

Trading is all about having a plan and then working that plan.  Find the stock setups that work and then look for the right entry/exit.  Think about what you want to do and be patient and let the plan work.  Sounds similar to what a project manager does, no?

If anyone out there’s interested in learning more about trading, feel free to drop me a line.  For much more knowledge folks on the subject, check out stocktwits.com or some of these good traders, investors and thinkers in the space:

• Art of Trading - @traderstewie on Twitter
• Gtotoy Blog and Day Trader Boot Camp – @gtotoy on Twitter (i recently joined DTBC and love it!)
• Michael Bigger – @biggercapital on Twitter
• Investing with Options – @steveplace on Twitter
• Joe Fahmy – @jfahmy on Twitter
• Barry Ritholtz – @ritholtz on Twitter
• Joshua Brown – @thereformedbroker on Twitter

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.

My opinion?

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?