SOA ServiceOriented Architecture Predicted to Increase in New Year ...

IT governance models must evolve to make the best decisions on a service oriented enterprise architecture. Sean Rhody makes some predictions for the new year, including the acceleration of service oriented architectures, SOA. ...

... "Service orientation offers the possibility of real advances in IT - advances that can be coupled strongly to business value. It also requires organizational change and modification to IT governance that many folks have yet to really tackle. It's a lot easier to change the software than it is to change the people who run the software " ...

SOA ServiceOriented Architecture Predicted to Increase in New Year: Via SysCon: Holiday Wishes ...

Agile vs Big-Bang Project Delivery; Argument Solved

For years now, proponents of realistic IT approaches have been touting the importance of agile or spiral development. And aficionados of traditional "plan everything up front" approaches have been counteracting this by stating the need to agree to a fixed scope, and stay on time and on budget.

Several weeks ago I mentioned an excellent book that addresses this subject; Software Projects: Evolutionary vs. Big-Bang Delivery, by Felix Redmill. I finally finished reading it, and it points out how to resolve the differences, with a reasonable and sensible approach.

Again, the book is expensive (well over a hundred dollars), but can be found used for around fifty dollars on Amazon.com.

Below, I've paraphrased and summarized the key points:

• Be sure to understand and state the business objectives up front. This is too high level for an adequate estimate, but it's a start.
• Then conduct a feasibility study, analyzing as much detail as possible before authorizing the project. Most organizations skip this step, with bad effect. Aim for an aggressive but realistic target.
• Beware of random constraints assigned by senior management, with no strategic cause. Most projects fail because they attempt to hold to unrealistic or arbitrary constraints. If necessary, document the risks of adhering to the arbitrary deadline and review with them. Negotiation tradoffs in scope, time, or cost as needed - or break the project into multiple phases.
• It's still too soon for a definitive estimate, but the results of the feasibility study should be submitted as an "order of magnitude" estimate, along with risks and a plan for mitigating them. This becomes the business case for the project.
• Make sure senior management understands that change is inevitable as the project progresses. But this change should be still be governed and weighed against the business objectives. Reassessment gates can be used to reset expectations of when the project ends.
• Not all change should require governance. Project managers should have the leeway to use their own judgment to change tactics accordingly as long as it's within the business objectives. They should not just "follow procedures."
• It should not be expected that all work will be done within the confines of the original document. For instance (and this is my example, not from the book), if implementing a purchased software project, a feasibility study would have been done before the software was purchased, configured, and tested. Upon configuration or testing, new discoveries/issues can (and probably will) occur. The only way to truly mitigate this is to do a pilot. Aside from that, expect changes.
• This is a HUGE culture change for most organizations on the part of senior management. Without this level-setting, management will expect all work to be held to the original estimate, and judge success against it. This is the key reason why most IT projecst are seen as failures. We must manage stakeholder expectations (and that includes senior management).
• Project progress should be weighed regularly against business objectives and not the completion of tasks. These objectives and the project's ability to meet them should be reassessed at each phase gate, with escalation of any variances to management. Again, this is the time to reset when the project ends, if necessary. This is also a huge culture change for senior management in most cases.
• Scope should be revised as needed and documented at each step, so there's a record of the approvals and rationale for changes. Reasons of variations should be captured as lessons for future estimating.
• Agile or evolutionary development is not an excuse to ignore change management. But change must be expected. To hold firm to a detailed schedule up front is not realistic for most IT projects.
• Maintain close contact with users throughout the project to assure success.

This sounds like a sensible approach, but does require level-setting with management. Again, many project failures are a result of not setting the right expectations with management. Otherwise, a project can be a complete success, but management is dissapointed. This destroys morale and unfairly judges the project as a failure.

I recommend the book for those who want to learn more, as the book goes into far more details and offers examples, processes, etc. Here's the Amazon link...

http://www.amazon.com/gp/product/0471933430/102-4494239-8790520?v=glance&n=283155

Project Work Packages; The Importance of Delegation

I read this story on Stephen Covey's website about his inspiring interview with a well-respected Naval captain. They key success factors for this captain were his ability to delegate, and his trust in his subordinates. This trust and delegation truly inspired passion and accountability in his people (something we've promoted here at PMThink as well).

It reminded me again of the importance of Work Packages in project management, where we assign deliverable (or group of deliverables) to a work package owner, and give them full accountability of managing the details to "make it so" (as Captain Picard of Star Trek: The Next Generation would say).

Here's Stephen Covey's account of this interview:

I was training U.S. Navy officers in leadership during the dot.com era, when someone told me about an exemplary leader named Captain David Marquet, Captain of the U.S.S. Santa Fe, who never lost anyone, in spite of the hellish conditions submarine personnel are required to endure. An opportunity arose, which I jumped at.

I was invited to board Captain Marquet’s sub and interview him. Never before had I observed such empowerment. We stood on the bridge of this multibillion-dollar nuclear submarine with a football field of vessel in front of and behind us. A young officer approached the Captain and said, "Sir, I intend to take this ship down 400 feet." Captain Marquet asked about the sonar and sounding and then instructed this young man to give us another twenty minutes on the bridge before carrying out his intention.

Throughout the day, people approached the captain intending to do this or do that. The Captain would sometimes ask a question or two, but then say, "Very well." He reserved only the top decisions for his own confirmation and empowered others to make the rest. He said he wanted to empower his people as far as he possibly could within the Navy’s confines. He felt if he required them to own the problem and the solution to it, they would begin to view themselves as a vitally important link in the chain of command. He created a culture where those sailors had a real sense of adding value.

Months after my sub ride, Captain Marquet wrote to inform me that the U.S.S. Santa Fe was awarded the Arleigh Burke Trophy for most improved submarine, ship, or aviation squadron in the Pacific.

All in all, a very inspiring reminder to us that we don't need to be managing every last detail of our projects, and instead must have faith in our most valuable asset---our team. This "distributed accountability" approach is a surefire way to encourage and exploit team synergy. Just pick the right people, give them guidelines, and get out of the way.

Microsoft to Acquire UMT IP.

With the next version of Microsoft Project in pre-release beta, this may be a little late for Microsoft to really include UMT Portfolio Management into P12 but this is certainly a move in that direction. See the MS press release at Microsoft to Acquire UMT, a Leading Provider of Portfolio Management Software and Solutions.

Results vs. Process - Revisited

The other day, I posted a blog on results vs process. The conclusion I came to was that for projects (which are by nature of limited duration), it was more important to do what it took to assure good results than to blindly follow process.

Of course, the definition of "good results" must be agreed upon. I also added the caveat that this does not apply to processes that must be observed to assure adequate results.

While I still fully believe this approach is true as a guiding principle for project managers, I've come across two good arguments in defense of process in general:

1) Results are often uncontrollable, while processes (if maintained) can at least assure more consistent results over the long haul. Uncertainty is a given, and good processes will allow for that and plan for that.

2) Conflict should always be expected, and should be used to improve processes rather than be seen as an impediment to results. Conflict is a good thing. Unresolved conflict is not.

My clarification of "results over process" is this:

• When defining processes, don't make the processes so heavy and bureaucratic that they impede results.
• Introduce processes slowly. Don't expect overnight results; Follow a maturity model and strive for continuous improvement.
• Relentlessly search for less invasive ways of accomplishing control.
• For each potential new process, use the"Five Why's" (asking "why" five times until you determine if the process in question is really needed). If in doubt, don't add it.
• Allow room for people to make decisions. If a principle will work just fine to help keep people on course, then don't institute an unnecessary process. Not everything can or should be "process-ized." Generally, aim for principles over processes wherever possible.

I do think Toyota has it right. By focusing on long-term results (i.e. continuous improvement) over short term results, continued success is more assured. By we don't want to unnecessarily impede short term results either. We can walk this balance by keeping our processes lean and giving project managers the freedom and confidence to do what is right to successfully deliver a project. People are ultimately our best asset.

Troubled Project Dilemma: Fix or Kill?

We've all been faced with projects that run into unexpected problems. It happens to the best of us. Sometimes, despite the best of planning, things can begin to go south. The situation may be that the project now risks running overbudget or being delivered late, or it may be that unanticipated quality problems were discovered.

Our first action should be to not overreact and to try to fix what's wrong, working out alternatives if needed. But if all else fails, then we may be faced with a tough decision. Do we continue to fix it, accept the situation and manage expectations, negotiate a change in schedule, budget, or scope---or do we kill the project?

Similar to going bankrupt, killing a project late in the game should only be a last resort. Even then, there's a right way and a wrong way to go about doing it. The article below from High Context Consulting offers some good tips, most of all that an alternate solution must be proposed.

Specifically, it says:

• Build a case including alternate options to meet original needs.
• Gain support of stakeholders and a champion.
• Present recommendations to leadership.
• Do not play the blame game.
• Learn!
  
  Here's the full article...
  
  High Context Consulting � Blog Archive � On Killing Projects

Making Megaprojects Work: Tips for Successs

There's an excellent article in Computerworld on managing megaprojects. I've summarized the lessons into three key points:

1) Understand the business need and engage stakeholders; If everyone's on board up front, it'll be a smoother ride.
2) Don't skimp on change leadership and training; It can make or break your initiative.
3) Expect breakdowns! Big change isn't easy. Encourage feedback, but make people part of the solution instead of part of the problem.

Great advice for anyone managing a megaproject that brings fundamental change to an organization.

The full article is below....

Managing Megaprojects - Computerworld

VOIP Project: Voice-Over-IP ...

The VOIP transformation project is relatively high-risk: newer technology, questionable scalability, increased cultural change, and impact to a critical business function: communications. J. Nicholas Hoover discusses the pitfalls of a voice-over-IP phone project

... "Anyone thinking a switch to a voice-over-IP phone system will be smooth and easy should remember Ruth Harenchar's ruby-red nail polish. At the Hobart West Group, where Harenchar is CIO, the company's VoIP project required tough decisions, like whether to spend money training existing IT staff or hire expensive consultants. It meant learning to live without certain common telecom features in order to get the savings the company wanted. And it involved helping employees through the culture shock of replacing the familiar ... " ...

Via InformationWeek | Voice-Over-IP | VoIP Gotchas ...



Here are some relevant references on VOIP implementations:

Via NetworkWorld: The ROI of VoIP: "When it comes to VoIP, most network managers are satisfied that the technology works. The challenge is developing cost analyses: What will the new technology cost to roll out and support, and what benefits can companies expect to reap? "

Via NetIQ: VoIP in Action: "OK, you've moved beyond the deployment stage of your VoIP project. Your first group of VoIP phone users are happy and you've got high levels of availability and call quality. Now what? In the management stage, you need to keep those users happy with consistent availability and high call quality. "

Managing VoIP Implementations Effectively: "Voice over IP (VoIP) is the hottest telephony technology. Consumers and corporations are looking to reduce costs by deploying VoIP systems. The challenge, however, is that the technology is so new that few project managers have expertise in managing VoIP implementation. If you are interested in or responsible for implementing VoIP at your organization, this is the course for you. "

IT Governance Process: Drive Business Value ...

IT governance seen as hot trend for 2006. CIO's will leverage business leaders to make investment decisions and increase the business value of the IT project portfolio. Summit Strategies publishes its annual list of seven IT high-impact trends in the information technology space. ...

... "CIOs Get Business Value Religion. Leading-edge CIOs will implement sophisticated, business-focused IT governance processes and tools to increase their credibility with internal business sponsors and free up funding to support strategic business/IT initiatives. " ...

Via Tekrati Research: IT Vendors Face Fundamental Changes in 2006, Says Summit Strategies ...

Project Management Audit

It's not often that you get the opportunity to look inside someone else's project in an objective way while it's still in progress. This audit report from the Treasury Board of Canada is interesting in the depth to which it goes in identifying risks - and in showing the importance the secretariat gave to addressing the concerns.
One issue that will be familiar to many people working with a client (internal or external) to deliver a system is the availability client staff. One can almost sense the Project Manager's frustration at not being able to access knowledgable staff even though the importance had been made clear at the outset and the budget for back-filling approved.
Another familiar issue is the argument amongst stakeholders over the project scope. This is the one item that the audit team rated as High Risk. And credit to the secretariat for setting up a new steering committee chaired by an Assistant Secretary to address the issue.
All in all, an intersting read.
Project Management Audit - Treasury Board of Canada Secretariat - Part 2 of 2

IT Governance: COBIT 4.0 Release ...

The new edition of COBIT 4.0 is ready for release and focuses on the role of IT governance. ...

... "The IT Governance Institute (ITGI) will release on 16 December a significant update of Control Objectives for Information and related Technology (COBIT), an internationally accepted IT governance framework used by major companies worldwide. COBIT provides an authoritative, international set of generally accepted practices that help boards of directors, executives and managers increase the value of IT and reduce related risks. " ...

IT Governance: COBIT 4.0 Release: Via ISACA: COBIT 4.0: Major Update to International Standard Helps Businesses Increase IT Value, Decrease Risk

Tag: IT Governance

Business IT Alignment: Service Catalog Touchpoint ...

Today's IT services transformation is enabled by a business-oriented service catalog with a robust set of supporting service-delivery processes. It is the service catalog that is the key touchpoint driving alignment of IT with the business. Rodrigo Fernando Flores explores the challenge of aligning IT with business goals and the role of business-expressed services in a IT service catalog. ...

... "More and more leading IT organizations are deploying a Service Catalog as the cornerstone of their shift to a more service-driven and customer-focused approach, or as the foundation of their ITIL initiative. As a vehicle for communicating and marketing IT services to both business decision-makers and end users, the IT Service Catalog can help address this trust deficit on two fronts. " ...

Business IT Alignment: Service Catalog Touchpoint: Via TechRepublic: IT Service Catalog-- Rebuilding trust between IT and the business

Results vs. Process; Which is More Important?

In the project management world, we've all been hearing about "process" for years, and of course most of us have been indoctrinated in PMI principles. And process is important, because it gives us a roadmap to follow and allows for continuous improvement (provided we learn from mistakes and tweak our processes accordingly).

But as the saying goes, the map is not the territory. Ultimately, in order to achieve results on a project, we need to know when to streamline certain processes, or even break the rules entirely, especially when faced with day-to-day challenges.

Companies like Toyota live by processes (even over short-term results), and do very well. But that is organizational strategy -- and a good one at that. The idea is that if processes are monitored and improved over time, then long term results will ultimately be realized. With project management, on any given project we cannot afford to wait years to see the fruit of our process improvement labors pay off. We're on a limited timeline, and must show results.

Granted, we still must conduct lessons-learned sessions and regularly revise gaps in our project management process (constantly looking to streamline), but from a tactical project management standpoint, results must come first.

This is why I conclude that, when it comes to managing a project, results are more important than process.

But there's something even more important than results, and that's people.

Ah, but that's the subject of another blog (to paraphrase the ending of the film, "The Jungle Book" -- the Sabu version, not the Disney cartoon).

Project Software: Hosted Solutions Require Network Monitoring and Optimization

The future of software is in the utility computing model, such as hosted applications. Matt Hamblen shares the experience of managing networks when leveraging a hosted architecture for project management software. ...

... "More than 250 Perini workers at the company's headquarters use project management software called Expedition, which is hosted by application services provider LoadSpring Solutions on servers accessed over T1 links in a WAN. " ...

Via Computerworld > Radio killed the internet star - until builder downgraded quality

ITIL ITSM Service Management Strength: HP Recognized ...

Forrester recognizes HP leadership strength in global delivery infrastructure management and ITIL IT service management consulting. ...

... "The report singles out HP's leadership in IT service management methodologies, evidenced by the number of ITIL consultants HP has trained or acquired. Further, HP achieved the highest weighted score among all vendors in the Strategy area. " ...

ITIL ITSM Service Management Strength: HP Recognized: Via HP: HP Ranked a Leader for Global Delivery Infrastructure Management by Independent Research Firm ...

ITIL Web Seminar: Speed Implementation ...

Upcoming ITIL web seminar focuses on accelerated implementation. ...

... "TeamQuest Corporation, the global leader in IT Service Optimization (ITSO), will hold a free Webinar to demystify IT Infrastructure Library (ITIL) at noon on Wednesday December 14. Noted ITIL expert Ron Potter will provide real world examples and an overview of ITIL to show how quick wins can help speed implementation. This Webinar will discuss how software solutions can be leveraged across other ITIL processes and disciplines to speed implementation and reduce start-up costs. " ...

ITIL Web Seminar: Speed Implementation: TeamQuest to Host ITIL Webinar: Via Yahoo! Finance

Project Management Useful Analogies (or Jokes)?

Some of these you may have heard, some perhaps are new. Sometimes helping people to understand requires an analogy or "funny" anecdote. Let us know if any of these work for you! My comments are embedded here for you also in brackets [].

1. It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women. [my favorite - throwing bodies at the problem is usually not the right answer]

2. Nothing is impossible for the person who doesn't have to do it.
[watch it when someone says that someone "JUST" has to do X]

3. You can con a sucker into committing to an impossible deadline, but you cannot con him/her into meeting it.
[when they squirm about a date, figure out how to help them and note the risk]

4. At the heart of every large project is a small project trying to get out.
[break the work into "bite-sized chunks"]

5. A user will tell you anything you ask, but nothing more.
[requirements gathering - yeah, good luck with that. better to observe them in action, and show them prototypes and let them react.]

6. Of several possible interpretations of a communication, the least convenient is the correct one.
[true!]

7. What you don't know hurts you
[also known as "the devil is in the details"]

8. The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.
[read that one again]

9. Everyone asks for a strong project manger - when they get one, they don't want one.
[amen!]

10. Fast - cheap - good - you can have any two.
[see other posts on the triple constraint]

Thanks to www.funny-haha.co.uk for these! See that site for many more!

Project Planning Tip: Facts are More Important Than Theories

When planning your project or solving a problem, always remember that facts are more important than theories. This means that agile approaches, rolling wave planning, prototyping, etc. should be used where appropriate, in order to base decisions on facts. The alternative is to plan all future phases in detail up front, which is tantamount to basing your decisions on pure theory.

Likewise, the project approach itself should be based on a visit to the customer to see how things are currently done, and get a true understanding of what is needed. Often, what's really needed isn't what is stated in the project request.

In A Scandal in Bohemia, Sherlock Holmes (by way of Sir Arthur Conan Doyle) said, "It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

This is sage advice for project managers as well.

Project Estimating; Triple Constraint Must Stay Firm

Here's a great article from TechRepublic about project estimating and forecasting. It cautions that one of the worst things to do is to try to force a project to fit within an arbitrary management deadline. That means project managers must defend the right plan or suffer with poor results.

A properly estimated project must be based on planning, and be managed to the triple constraint of scope, time and cost (and of course, at PMThink we've discussed other potential variables, such as quality, risk, customer satisfaction, and more).

Here's TechRepublic's advice to CIO's:

Project managers talk about a project’s “triple constraints” of scope (work), time (schedule), and cost (budget)... For the team to make decisions that are closely aligned to the way you would like them to be made, you must clearly state the project priorities. There’s no such thing as “all three variables are equally important.”

Read on for more details or proper estimating and forecasting...

How to accurately estimate and forecast in project management

Information Technology Profession: Understand the Skill Shifts

IT leaders value business, functional, and project management skills, but are not investing in the entry level programming skills in the U.S., where early talent is developed. Christopher Koch, CIO, challenges the recent data that the IT workforce has regained its Y2K size and everything is just peachy. Further review of the data shows major structural shifts in skills and jobs have occurred. ...

... "In a survey of 82 companies that began earlier this year and is continuing, the Society of Information Management's team of academic researchers asked which skills IT leaders thought were most important to keep in house today. The top skills were all related to business process or project management. " ...

Information Technology Profession: Understand the Skill Shifts: The Structural Shift in IT - Koch's IT Strategy - Blog - CIO