The most common result of this ‘evolution’ is that a lot of current projects are being carried out, yet no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon. The way to solve this is to increase awareness, including:
1) A recognition that IT projects do not belong to IT, they belong to the enterprise as a whole, even if various non-IT parts of the enterprise are assigned responsibility for some sub-set of projects.
2) An understanding that projects still originate the same way: a problem, challenge or opportunity is identified, or a new idea to improve the business is suggested. Sources for suggestions range from front-line staff to objectives stated in the enterprise’s strategic plan.
3) The realization that dozens or more project ideas may be in play at any one time, but the average enterprise does not have the resources to do them all. It must pick from the candidates which projects will indeed be resourced and proceeded with, and it must continue to do this as current projects are completed and resources are freed up.
It all boils down to best use of limited resources. The term that has emerged to describe all this is Project Governance.* The most common analogy used to describe this governance is “gating”: a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, while the rest wait for another chance when more resources are available or are eventually dropped from consideration.
It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development (commonly called Construction). As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the enterprise.
–
*In some ways, governance of IT has emerged a lot sooner than the newer Corporate Governance that deals with all aspects of a company’s operations in order to meet with new compliance laws brought around by the Enron failure and the like. Many IT departments already recognized they had their own mess to deal with, hence Project Governance.
David Wright has been an IT Business Analyst for 25 years and is the author of Cascade: Better Practices for Effective Delivery of Information Systems in a Multi-Project Environment. You can find more of his writing in the latest issue of Cutter IT Journal and at his blog, Business Analysis. You can also follow David on Twitter.
IT projects have rightly earned the reputation over the years as places where lots of money goes in and no value comes out. We are all aware of the CHAOS studies by the Standish Group that show that most IT projects are also usually late, and a large number are never even completed(!).
How did this happen? My (untested) theory is that computers were first used to automate rote manual tasks, and the results from these projects were valuable and easily seen as so. This led to the belief that automating most anything was going to be good for the enterprise, but as projects moved into more complicated/complex aspects of the business, the returns of pure automation began to diminish. Unfortunately, it was still assumed that the value was there, and it was a complete assumption; actually determining what the value was to be was done only rarely.
Early computer projects were really run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well, so the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.
So, projects proceeded into more complicated areas of the business, and they started to break down. Some failed, and now management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable). How did they all get started anyway?
Come back on Friday for Part 2 of David’s post on choosing the right IT projects!
David Wright has been an IT Business Analyst for 25 years and is the author of Cascade: Better Practices for Effective Delivery of Information Systems in a Multi-Project Environment. You can find more of his writing in the latest issue of Cutter IT Journal and at his blog, Business Analysis. You can also follow David on Twitter.
Donna Fitzgerald, Research Director at Gartner, recently blogged about the Enterprise Project Management Office and its importance to the organization:
[T]he role of the EPMO is to help the organization make sure that strategy (real strategy, not just words on paper) is realized through investment in projects and programs. If you are tempted to say “Come on, Donna — that’s what we do now,” then you are either in the 5 to 10% of companies where it is true, or you are mistaking the concept of “strategic alignment” for strategic realization. One says I’m somewhere in the general vicinity of the strategy — the other says I have direct line of sight to the strategy and can tangibly show how this project or program contributes.
She emphasizes that this model is different from what you might have read about EPMOs – it is “small, lean, mean and agile.”
Do you have an EPMO? How does it perform in terms of helping you to reach your strategic goals?
–
Related stories:
TechNewsWorld: Why Should We Let Your Department Live? PMO Survival 101
Harvard Business Review: The Execution Trap
Project Times: Getting Strategic Projects Off the Back Burner
Project Times writer David Donaldson has highlighted the difference between education (transfer of knowledge) and training (transfer of skills). One aspect of training that is not involved in education alone is hands-on practice.
Tell. That is education, a critical first step. We need to know what we are doing.
Show. This is perfection. We know it, now we see how it is supposed to be done.
Do. This is where true learning happens. A student who can demonstrate a task now truly has the skill.
So how can you decide whether or not education is enough? According to Donaldson, training should always come into play.
At great expense we have built the perfect machine for the job, but if no one is trained how to operate that machine it will surely fail. [...] When considering the necessary elements of a successful project, remember, the proper amount of education coupled with quality training is an investment that will pay dividends.
InformationWeek has published an article on how to implement an analytics methodology for better decision-making.
Decisions made based solely on intuition, gut feelings, and years of experience, while valuable, tend to be less effective than scientific methods. Analytics provides a methodology that incorporates crucial variables and provides simulations that show the impact of our choices before we implement them.
The steps include:
1. Define the problem
2. Identify relevant factors
3. Focus on data collection and preparation
4. Model the solution
5. Report the results
6. Implement the decision
7. Follow up
Does your current decision-making process include these steps? How could you implement them in order to enhance what you’re already doing?
Positivity is not often listed as a key characteristic for project managers, but ProjectConnections writer Carl Pritchard believes it is essential. In his latest article, he talks about how he and his wife went to see the Dalai Lama speak and how he continued to focus on the positive, even when audience members tried to get him to talk about depressing things.
How does all this tie back to our project worlds? As project managers we have amazing opportunities to create something new, to experience the capabilities of others and to construct legacies both personal and organizational. We create artifacts. We engage others. And it’s very easy to drop into a mode where we focus on the challenges, the adversity, and the hills yet to climb, without looking back on the landscape that we have already altered. The amount of opportunity and power that affords us in our profession is staggering. And the ways in which we exert influence can be staggering, as well.
How can you be more positive when managing projects and interacting with team members and stakeholders? Would it make a difference to the success of the project?
We at Journyx would like to wish our friends in the United States a very happy Independence Day. Hopefully you have today off from work despite it being the 5th of July. For those of you who don’t, we won’t make you read the typical project management and business improvement content. 
In a meeting last week, a Journyx manager brought up the story of the American Revolution. The British came out, all lined up, with better equipment and better numbers, and the colonists, who were shooting from behind trees, won the day. The lesson here is that perhaps you don’t have the strongest sales numbers right now. Perhaps morale is down from having lost employees and clients. Perhaps your company is concerned about the new challenges that will come when the recession is over but all top-line growth strategies were cut last year.
Not to worry. Keep fighting. A great woman once quoted Arthur Ashe to me, and it still resonates: “Start where you are. Use what you have. Do what you can.” It’s not the time to lie down and give up. It’s the time to take responsibility for your company’s welfare and success, regardless of your level or role. Step up and do something you can be proud of!
A new Project Times article has highlighted the reason why traditional PM methods and agile methods for risk management collide. The author notes that both are valuable, but he supports the agile way for the following reason:
The variability in complex software projects is what undermines traditional risk management in my view. We try to expend all of our effort in up-front risk management. Rather, we should expend most of our efforts towards figuring out what we do and do not know. We should decide how to design and code this particular widget I.e. do some of the project work before trying to predict risk. Let the risks emerge from our efforts rather than trying to predict them.
What’s the best way to go about integrating traditional and new agile methods, both in risk management and in other areas? The best way is to find common ground and understand exactly which aspects of each best apply to your particular organization.
Admit it – you’ve always wanted to know a little bit more about your friends at Journyx, the people who make your life easier by providing the top web-based solutions for time tracking, invoicing, project accounting, resource management, cost reporting and more. Well, the wait is over. Over at the Journyx Facebook page, we are honoring our valued (and quirky) employees via…
The Journyx Employee Hall of Fame!
Head over there now to learn more about Scott, our Grumpy IT Guy, or Troy, our less grumpy Technical Support guru. Better yet, “like” Journyx on Facebook so that you won’t miss all of the other employees who are yet to be featured. (We will pretend that you are doing so for sheer love of Journyx and not for the chance at an iPod Touch.)
Lisa Anderson asks the question in her latest article at Project Times.
In my experience in working with multiple companies across multiple industries and globally, I’ve seen many projects succeed while others fail. Although there are countless types of projects, ranging from a new product launch project to a system implementation project, there doesn’t seem to be a pattern of success among the same type of project. Instead, I’ve discovered that one of the hidden keys to success is vision.
She goes on to write that vision involves seeing the integration points and impacts, the optimal sequencing pattern and impacts, and potential roadblocks. “Practice improving your ability to see (vision), and emphasize and value this skill with your project team. You’ll not only deliver significant project results but you can utilize this skill in your personal life as well to achieve amazing results – why not give it a try?”
How do you use your vision to stay on top of potential problems and anticipate results?
0
Back to top
