Joe McKendrick, editor of eBizQ, interviews Journyx CEO Curt Finch on things companies need to know about cloud deployments.

Q: Is cloud-based ECM something that organizations are already doing?
Curt Finch: Yes, but mostly this is true with startups or VC backed firms. Some B2C operations, like restaurants, have their web page on Facebook now instead of having their own site.

Q: Will some ECM services be leveraged through public clouds, or is this mainly a private cloud play?
Finch: It's possible but the only advantage I can see is if you expect massive peak load spikes, like with the Superbowl or something like a natural disaster.

Q: Are there security implications to public or private ECM adoption -- or regulatory barriers?
Finch: If you trust the cloud vendor -- such as Amazon -- then there aren't really any security implications. But do you know for sure you can trust the cloud vendor?

Q: Will content remain on local systems, or will that also be moved to the cloud?
Finch: It would seem sensible to either move all of it or none at all.

Q: Does cloud offer the possibility for more widespread ECM adoption?
Finch: Perhaps. Complex systems are better managed by their writers, like Vignette.

Q: Will it truly put the "E" in ECM?
Finch: It's doubtful. The cultural and organizational impediments won't change, will they?

Head over to eBizQ for the rest of this interview!

Vincent McGevna, Principal at Vincent McGevna Consulting, wrote a great article over at ProjectsAtWork that we think you should take a look at!

While a project plan contains more than just a schedule, the schedule is arguably the most important aspect of that plan. For the project team, the schedule defines what they need to do and when they need to do it. Outside of the project team, it is the most visible element of the plan, and many consider it to be the plan.

The project team is tasked with creating the end product of the project. The schedule, developed with their input, lays out how they, as a team, are to go about creating it. It should reflect project priorities, the best sequence, and the integration of all of the work of the individual contributors. As we will see, a good schedule will have a lot to do with the delivery date, and not just by predicting that date. It will also impact the final quality of the end product. And, the project is really not over until the customer is satisfied with the quality of the product.

Management needs to know the key milestones, especially the completion date of the project. Then they set customer expectations — when can each customer expect to receive promised deliverables. Customers, in turn, may need to know this as it drives their schedules. (How many times have you had your schedule disrupted when a promised delivery from an outside vendor is late?) With realistic schedules, customer expectations on timing, quality and scope can be met; with optimistic schedules, unrealistic expectations result in disappointed customers.

Many organizations create a roadmap of future projects and use this to set long term goals, which are also shared with customers so they can do their long term planning. In fact, the roadmap frequently reflects the needs of key customers; meeting those needs can be very important in a competitive environment. Still, the roadmap is driven by the availability of the necessary resources. So it’s important to know when those resources will be available; that is, when will they complete their current assignments. Again, this requires realistic schedules. Thus your current schedule not only sets your customers’ near term expectations, it also drives the roadmap which sets their long term expectations.

Head over to ProjectsAtWork to read the rest of the article!

If you live in Texas, you know about SXSW. If you don't live in Texas, chances are still pretty good you know about SXSW. And if you DON'T know about SXSW, you need to stop what you're doing and listen up!

SXSW is the annual music, film, and interactive conference and festival held in Austin. SXSW Music is one of the largest music festivals in the United States, with more than 2,000 performers playing in more than 90 venues around downtown Austin over four days. SXSW Film has become one of the world's premier film festivals, focusing on new directing talent. SXSW Interactive has attracted a strong following among web creators and entrepreneurs. Its focus on emerging technology has earned the festival a reputation as a breeding ground for new ideas and creative technologies. The festival has grown every year, most recently bringing around 15,000 to 20,000 registrants to Austin.

The dates for the 2012 Conference are:

Interactive: March 9–13
Film: March 9–17
Music: March 13–18

Okay, so why am I telling you all this? We need your vote! Journyx CEO Curt Finch has submitted a presentation for the Interactive conference. People can vote on the presentations they would like to see at SXSW for the next 2 weeks. Public votes will account for 30% of the total vote. We would love it if you'd take just a minute and go here to vote for Curt's presentation: VOTE HERE

And if you are planning to attend SXSW this year, let us know in the comments section. We would love to meet you!

Ahhh…the age old question. Or at least one that seems to come up from time to time. It’s certainly a question that has frustrated me for a while. When should the project manager become engaged in the project? After the sale? During the sale process? From inception, working right alongside Sales to map out an estimate and close the deal with the client? You could say ‘it depends’, but I’m not sure that’s a good answer either.

About a decade ago I worked for very large aviation and engineering firm where I specialized in managing web projects primarily for internal customers. What that means is I led internet and intranet projects for individual business units within the organization. The whole sales process was mine. There was no marketing involvement, just the internal sponsor initiating a project request which was my cue to find out their needs, map out requirements, and then turn around a price estimate that we could move forward with. I would sometimes take a developer with me to speed up the process of documenting requirements and a proposed solution if I wasn’t completely sure, and that would get me to a good price point quickly for the internal client. None of these were multi-million dollar engagements – the largest was probably close to $100,000. But you can see how informed I was as I assembled my team and began to work with the client on the project. There were no gaps or cracks through which information could fall. I had been with the project from inception and knew everything.

Fast-forward ten years to larger projects I was leading for a professional services organization. The Sales team completes the deal with a price and a proposed solution and starts throwing these projects over the wall to me and the other project managers. We have only the knowledge we can extract from the account manager during a phone call and we have the statement of work…and not much else. No wonder when I showed up at the client site for project kickoff I was usually bombarded with questions and expectations that were different from what I was telling them was going to happen on the project.

It’s extremely important – no, it’s critical – that the project manager be a part of that sales process. There are too many risks involved – including budget and other financial risks – when the individuals who will actually be carrying out the project aren’t part of the team that also prices the project and drafts a solution. The project manager should be allowed to act much more as an engagement manager – running the concept or project request from inception to deployment. When you just hand it over the wall, you create a do-over point where knowledge must again be transferred and you have too much risk for important details just falling through the cracks.

Summary

So I’ll ask the question again, should the project manager be involved in pricing the engagement? My answer is an absolute ‘yes’. And much more than that – the project manager should be involved in the whole account management process of getting the project request to the ‘sold project’ point with a statement of work, price, draft schedule and a date for an official kickoff meeting. By involving the project manager, you have the best chance at not only presenting the right price, but then also ensuring that your project team and the customer will be on the same page when they sit down to finalize how the project will be run during the formal kickoff session.

About the Author: Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

Have you ever had that project or account that you just had to have? One that, for some reason, you saw as a make-it-or-break-it client initiative. Do you have a ‘succeed or die’ mentality? It’s probably a good thing if you don’t.

I realize there are times when we say, “I need to get that business or I may be in trouble.” That’s the nature of business. As an independent consultant, I’ve reached that crossroad a few times….I’m sure most consultants do. But do you go at it with that win-at-all-cost mentality? Or do you get creative? I vote for creative. A CEO of one company I worked used the win-at-all-cost approach….and it was not successful.

The Scenario

The organization I was working for was a small professional services company located in the Midwest; I was responsible for leading and growing the staff in Las Vegas. I was responsible for leading projects for one of their gaming/hospitality clients and as well as leading a project to perform a complete re-write of the software system that basically ran a local Las Vegas hospitality firm’s entire organization.

For the software re-write, we determined that the software would need to be completely abandoned as it had become a bad patchwork of software and add-ons. For some reason, our CEO wanted the contract badly and bid accordingly – low enough to win the business. However, we were much smaller than our well-known competition causing the client organization some anxiety. The client CIO felt that we would likely introduce change order after change order to recoup the revenue we were giving up in our winning bid. So our CEO pulled out the showstopper…he guaranteed one price (which was in the $1 million-plus range) and no change orders…period. None. No matter what. Well, that sealed the deal.

The problem, of course, is that it became a budgetary nightmare for me as the project manager because it was priced too low and there was no way to add revenue through change orders. The client was understanding enough, but everything within reason that they asked for, we did. The work was eventually completed, but by the end of the project, it was more than 60% over budget and my hands were tied from finding ways to add any revenue to the project. I know that the CEO’s hope was that eventually more work would come from the customer, but both organizations eventually failed – the client’s from the economy and the vendor (my organization) from poor management and fraudulent tactics by the CEO.

Summary

As a project manager and as an independent consultant, I’ve never been in favor of a win-at-all-cost strategy. The go-for-broke mentality is not likely to win you long-term business and it can certainly cause your financial infrastructure to become shaky by betting everything on one project going perfectly and not breaking the bank.

As we all know, every project hits bumps…every project experiences some sort of issue or critical point. And nearly every project struggles to some degree to stay on budget. Plus, more than 50% of all projects fail to some degree. Putting too much hope in everything going perfectly on a project is a recipe for disaster. It is far better to strategize, and pick projects and clients that match well with your long term organizational plans and financial goals. It’s the best decision to price work to profit, not just to win no matter what. A win-at-all-cost mentality at the top of your organization can bring a company down fast - leaving everyone else to pick up the pieces with the clients you were faithfully trying to serve.

About the Author: Brad Egeland is an IT/Project Management consultant, business strategist, and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. He has been highly recognized for his ability to work with C-level business leaders in both startups and established organizations to create best practice processes for business management and project management and has overseen the creation and execution of multiple project management offices. He is a married, father of 7 living in Las Vegas, NV. He can be reached at brad at bradegeland.com or you can visit his website at www.bradegeland.com.

The following article excerpt comes from Project Times.

Many of the clients we work with are a “PMO of one.” Usually this person has been brought in to establish common processes and procedures around planning, managing and executing projects. Most often, there is a broad spectrum of project work being performed by varied project teams within the organization, including a range of maturity levels spanning from no established, repeatable processes to very formalized and documented processes.

According to the Project Management Institute, “Companies with greater maturity should expect to see tangible benefits that include better-performing project portfolios, efficiencies that come with better resource allocation, and increased process stability and repeatability.” [i] On the other hand, companies that are less mature tend to be reactionary, trying to dodge problems as they come rather than strategically planning and executing projects. Often, these companies have various groups working in their own silos, so there is no centralized view of resource availability or up-to-date project status. Project managers are consequently unable to prioritize projects or schedule them with accuracy. This can lead to lost opportunities and failed projects time and again. A new study on organizational maturity has confirmed the need for defined repeatable processes, finding that companies that use them have a much higher project success rate than those who do not.

So how can the “PMO of one” bring teams and processes together to get everyone on the same page, speaking the same language and doing things in similar ways? Here are some things to think about for establishing common project processes that can be adopted throughout the organization, providing better performance and tangible results.

Focus on the Critical Business Issue

There are a number of reasons why an organization would decide to unify its project management processes. It could be a response to client pressure, a desire for an additional competitive advantage, or part of the general evolution of the company. Other times, the lack of organizational maturity is leading to lost opportunities. Understanding the reason behind the shift will not only give you direction as to how you should approach it, but can also help project managers to find creative ways to address the issue.

Don’t just establish processes for the sake of establishing processes. Rather, let the fundamental issues you’re trying to address or avoid drive your direction. You might find, for example, that re-engineering your processes isn’t what you need at all. Perhaps providing increased transparency, visibility and collaboration around all of the projects across the organization better addresses the critical business issue.

Read the rest of this article from Project Times here!