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

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

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

But…what is a good process?

Is it one that works?   One that gets the job done?  Or…is ‘good’ measured in some other form?

Of course, if a process works it can be considered good…but it is the best process?  Good question right?

My measurement of ‘good’ is this:  Is the process the best one for you and your organization?

If yes…good for you.  If no…fix it.

But..before you can fix it, you’ve got to understand whether its the right process don’t you?

A million processes…which is right?

I’ve been moving back into trading the stock market recently.  Nothing major…very small amounts of money and its something I enjoy doing in my spare time (which isn’t much these days).  There are a million different ‘systems’ out there for selecting stocks/options with most of them proclaiming themselves to the ‘best’ stock picking system.

At the core of stock selection systems are two main methods of analysis: fundamental analysis and technical analysis.  Of course, there are some systems that combine the two forms of analysis but for the sake of simplicity, let’s stick with these two systems as the core of our stock selection processes.

Some investors argue that fundamental analysis is the only way to go.  They argue that the only way to select, and own, a stock is to find those companies that have sound fundamentals (according to their definition of sound fundamentals).  You then purchase that stock and hold it.  Some argue holding it forever…others argue that you should hold it for a certain period.  Many many different processes & systems for selecting and holding stocks using fundamental analysis.  If you want to learn more about fundamental analysis, check out the wide selection of books on fundamental analysis on Amazon.com (affiliate link).

On the flip side, many argue that technical analysis should be the main focus of your stock selection system.  Some traders argue that you only look at technicals but most of the good traders out there that use technical analysis keep one eye on the fundamentals and the other on the technicals.  Using technical analysis to select stocks, your main focus us reviewing the technical indicators using charts, stochastics and other mechanisms. Technical analysis is something that many technical people (engineers, developers, etc) can really get into because all the numbers, charts, indicators and graphs.  If you want to learn more about technical analysis, check out the wide selection of books on technical analysis on Amazon.com (affiliate link).

Within both camps are many many (many) different selection processes & systems.  Some are simple, like the CAN SLIM fundamental analysis system, while some are extremely complex and require large computer systems to analyze and determine the best entry point.  Some systems are manual and some are automated and some are a mixture of automation and manual review.  Some systems focus on stocks only while some focus on stock options.

Needless to say…there are a ton of different processes for selecting stocks/options and other investment vehicles.

But which one is right?

It depends.

You knew I’d say that, right?

It depends on your attitude towards investing.  It depends on your level of risk you are willing to take (or can take).  It also depends on your investing horizon….how long can you wait for a return? Are you retired and need income?  Or…are you 25 and can wait 30 years to take your gains?  Lots of different things to think about while trying to find the ‘right’ stock selection & investing system/process.

So what is a person to do?  Try them all out?  Can’t do that…too many of them.

But…what you can do is think about what fits your approach to investing and life.  What works best for your situation.  Do you want to keep an eye on your investments or are you OK with investing your money and letting it ride through the up & down cycles?  Your answers to these types of questions will help determine which approach is right.  Your answers will help you select the right process for you.

Choose the wrong process for selecting your approach to investing and you could be bankrupt. Select the right process…and you might go bankrupt too…but you would’ve at least had the best opportunity to succeed.

Selecting the right process

Selecting the right process for investing is much like selecting the right process for your organization.  Just because a process works for your buddy at his company doesn’t mean it will work for you at your company.  Just because it worked for you last year, doesn’t mean it will work for you this year.

Processes are a dime a dozen.  Walk into a room full of IT people and ask them what the best process is for “X” and you’ll get about as many answers as there are people.

That said…good processes are a dime a dozen too.  What’s good for one company/person may not be good for you.

Don’t blindly adopt a process because it’s the “standard” or because it worked for you before.  Take some time to think about that process, the steps involved and the people involved. Think about your corporate culture and what types of things work well for your organization.

If you work for a slow moving organization with a ton of bureaucracy, selecting a fast-moving process that requires very little approval from ‘on high’ might not be the best thing.   On the other hand…if you are in a fast moving start-up, you may not want to select a process for selecting and acquiring new technology that you used to use in your Fortune 50 organization.

The right process is different for everyone & every company.  The right process is what works for you, your team and your company.

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?

From that post, you’ll remember that cognitive dissonance is: an uncomfortable tension caused by holding contradictory thoughts simultaneously.

Cognitive Dissonance is everywhere in IT today, especially in the Project Management side of the house.

I think everyone would agree there are a lot of IT project failures.

Now…there are some arguments made by some about what ‘project failure’ means.  To me..failure means that the project didn’t fully realize the scope of the project, meet budget and/or meet the timeline.  Some argue that failure means only those projects that aren’t completed are failures while the others that don’t meet scope/budget/timeline are ‘challenged‘.   Regardless what term you give it, the fact is that something like 68% of IT projects either fail or are ‘challenged’. That’s 2/3′s of all IT projects that aren’t considered successful.

So….we have a 1/3 success rate in IT Projects….and we continue to follow the same project management processes and methodologies.  We continue to fund projects in similar ways.

That’s cognitive dissonance in action.

We continue to think that projects will succeed although we know that, statistically, the project is more apt to fail than succeed…yet we continue down the same path with an uneasy feeling.

The stakeholders know the project is most likely to fail. The CIO knows the project is most likely to fail.   Heck…many on the project team think the project is most likely to fail.

Michael Krigsman, who does a wonderful job dissecting and discussing project failure on his IT Project Failures blog, recently wrote a short article titled Three simple truths of failure.  The article is based on a Dilbert cartoon discussing complicated project plans and Michael dissects the cartoon perfectly…its woth the jump to read. In the cartoon & Michael’s analysis, the following three truths are provided:

Complicated plans don’t work

Wishful Thinking doesn’t work

The boss really doesn’t care

While I’d like to think that the boss does care, I’ve found that many times they don’t have the time to care.   I know one mid-sized IT group that had over 150 projects on their list…there’s no way the CIO had any knowledge or interest in all those projects.

More interesting than Michael’s article are the comments to the article….anyone with more than 6 months experience in the world of IT can empathize and understand exactly what the commenters are discussing, lamenting and describing….the world of IT Project Management is full of failures.

But…those failures shouldn’t be focused on a person or on a process (or lack of one).  Those failures exist because previous failures weren’t learned from and those lessons learned weren’t acted upon. Those failures exist because of poor leadership.

In an article titled When an IT Projects go right, its simple to make projects succeed…all you need is a clear vision, support and commitment of the stakeholders, an understanding of the problems to be solved and sufficient resources & staffing.

Wow….so THATS all we need to do to make IT projects succeed.

Those are very important aspects of good project management, but there has to be more to it, doesn’t there?

Do we implement a new project management process?  Get people trained in project management procedures?  Get people certified?  Hire more people?  Outsource the project?

I’ve seen organizations build project management groups and fill them with certified project managers…and fail miserably.  I’ve also seen IT groups bring in temporary project teams and/or project managers and succeed beyond their wildest dreams.

So what do we do?

Can it be as simple as clear vision, support, resources and proper understanding of project goals.

I think that’s where we have to start.

Make it clear what needs to be done. Make it clear what the people need to do.  Then make sure the necessary  resources and support are there.

Whether you use an agile approach to projects or the old tried-and-true waterfall approach, without proper vision, clarity of purpose and the proper support and resourcing, your project’s chances of success are approaching zero.

Maybe we don’t “fix” project failures…maybe we need to fix leadership within IT to ensure projects have a better chance of success.

What do you think?

The conference uses a double-blind review process to review papers and provide feedback.  In this double blind-review, reviewer’s aren’t provided with author(s) information and author’s aren’t provided information about the reviewers.

Good and fair process….and one that I’m about to completely tear apart today.

My submission, titled A Social Approach to Knowledge Management in Projects, was conditionally accepted for inclusion if I were to address a major concern on the part of the reviewer.

The main concern was a claim of plagiarism.

The reviewer believed that the author (me) had plagiarized a good part of the paper.  They pointed to a website that they claimed proved that the author had used content from and note cited.  That website was mine – http://ericbrown.com.

Plagiarism is defined as:

the unauthorized use or close imitation of the language and thoughts of another author and the representation of them as one’s own original work.

I can see where the reviewer might have thought plagiarism existed as some of the work in the paper has been previously published here on my blog.  I’m actually quite excited that someone out there found my site interesting enough to cite as the original source of something that might have then been used in a plagiarism matter.

While this could be considered a case of self-plagiarism (if you believe in such an oxymoron), it’s not plagiarism.  The conference organizer requested that I cite my own work published on this blog within my article and also rework the article to ensure that the majority of the paper was significantly different than any other paper / article I’ve written.

Because I don’t believe in ‘self-plagiarism’, and because I’m feeling a bit rebellious this morning, I’ve decided to withdraw the paper from the conference and publish it, in its entirety, as a PDF here.  You can download the full paper using the link at the bottom of this post.

In the paper, I try to look at ways to answer this question:

Can a project team use Web 2.0 / Enterprise 2.0 platforms to communicate and share knowledge during a project? Can this communication be indexed and mined to capture relevant knowledge about the project, project team members and project technologies without adding additional burden to the project team members?

Download a PDF copy of A Social Approach to Knowledge Management in Projects today

Enjoy.