Microsoft unveils Project 2010 Beta

Project Server 2010 Beta Yes, you too can get a preview of what’s coming in Microsoft Project 2010. Microsoft has released the beta for Microsoft Project Professional 2010 and Microsoft Project Server 2010. We’ve seen these products in the office for some time as HMS is a Microsoft Gold Certified Partner who has the Microsoft EPM Competency plus I worked on Microsoft’s EPM Partner Advisory Council for years and completed my participation on that council only recently.

But now you can start seeing what will be coming in the new product.

Among functionality that I think will be well received you’ll see:

In Project Professional:

Timeline View. This is like the Visio timeline bar that many people like for summary views
Team Planner. This interactive view lets team managers drag and drop tasks onto a team member’s schedule
The ribbon menu (also known as the fluid user interface)

In Project Server:

Integrated Portfolio and Project Server functionality. Yes, they’re together at last.
Project Data Pages. Not enough has been said about these but I think they may end up being the most powerful aspect of what people will now do with Project Server. The PDPs let you create forms to gather data and then use workflow to move data into different parts of the EPM system based on the context of the data at that stage of the workflow.

You can find the beta for Project Professional 2010 at: www.microsoft.com/project/2010/en/us/default.aspx.
The Project Server 2010 beta is at: www.microsoft.com/global/project/2010/en/us/RichMedia/secondary/server_home.html.

Creating an environment for project management

Too often in the project management software industry, we focus on functionality. We seemed caught up in the next feature, the cleverness of our programming and the frivolity of the next cute bell or whistle. Yet despite being the most mature of software categories (project management software was one of the first applications ever run on computers), over and over I see failed implementations.

What is common among the largest and most skill-laden firms in the country who have been unable to implement enterprise-wide project control systems? There are probably several answers to this but one of them for certain is the lack of an environment which supports a project control system. There is much to be said for better functionality and increased effectiveness of various algorithms and data storage techniques but if there is no listening from upper management for the proper implementation of these features and functions then there is no point to them.

So what can you as an IT executive do? According to Robert Graham and Randall Englund in their book “Creating an Environment for Successful Projects”, lots. Here are a few categories to consider:

Develop senior management support
There is perhaps nothing more important than this first category. If there is no understanding by senior management of what project management is, there is no hope of improving project performance. There are many techniques senior management can use to increase its support for the project environment. A project inventory for example, where every project in the organization is reviewed for status and performance. A mentoring program might also be effective. Having each senior manager adopt a project or a project manager.
Creating an environment for project management
Communication is everything and if the organization can adopt input from different parts of the organization then project then true project teams become possible. True project teams represent all departments involved in the project rather than the chinese wall method of throwing a part of the project over the departmental wall once finished. This method results in no one taking ownership of the project completing. A structure for interdepartmental communication is what is required to even start breaking up this kind of divisiveness.
Develop a process for project selection
Should you start every project that’s possible? Of course not. But do you actually have a formal process for selecting and prioritizing which projects are selected? This procedure is one that can make the difference between an organization’s survival or failure. Imagine choosing projects by virtue of circumstance then ending up in a situation where the projects you’ve got cannot be successfully completed by the skills available to your organization. Project selection can include whatever criteria you choose but consider some kind of cost/benefit analysis. You’ll want also to include some kind of risk assessment. One of your other criteria may be matching the project against the skills available to your organization. In our own firm, we recently no-bid the largest proposal we’d ever been presented with. I won’t bore you with the details but you’d recognize the company name if I mentioned it. The only problem with the proposal is that it was so large that if we started on it and failed, we’d put the entire company at risk of closing. The risk was just too high for the potential benefit.
Develop upper managers’ abilities in managing project managers
The number of organizations with this as a priority are few and far between but as soon as it’s mentioned, the usefulness of some kind of structured management of project managers is glaringly obvious. Are your project managers managed consistently? Are the criteria for evaluating the performance of the projects themselves even defined? The time for doing this is long before the project gets going. Once the organization is deep in the thick of a project and the heat is on, it becomes very difficult to change the rules on how project managers are to be managed. Start a program of training upper management on how to manage project managers. Better yet, include the project managers themselves in the training to get more ‘buy-in’ for the process.
Establish a project manager’s development program
If it hasn’t occurred to you by now, the importance of recognizing project management as a skill to be treasured can make all the difference to an organization’s success. As soon as that is recognized, a formal development program for project managers becomes an ‘of-course’. This needn’t be too extensive to start with. Any program with a track of any kind will at least set the stage for future refinements in the program. An element of this program that should be essential is budgeting time and money for these project managers to improve themselves. I can’t remember how many of our own users have had to take vacation time and pay for their own travel to attend user-conventions of the project control software their company depended on.
Make project management a career position
This kind of recognition pays back in two ways. First of all, you’ll attract good project managers to these positions. Secondly, your project managers will gradually become more and more effective if this is a career post with a future. The alternative is what too many firms do all the time. A project comes up and the employee with the least to do is thrown at the problem by upper management. This is, of course, because upper management does not realize the impact a trained project manager has on the outcome of a project.
Develop a project learning organization
My favourite book on this subject is by Peter Senge called “The Fifth Discipline”. I can’t possibly do it justice here but suffice it to say that none of what I’ve just described should be static. Your organization changes, flexes, adapts to the changing world around it. So should your practices and procedures! Don’t make the mistake of thinking that this is something to be written up in a procedures manual to be followed blindly until the end of time. Build into your procedures and practices, procedures for adapting and improving the structure.

Without an environment to support it, any project management system you try to implement has almost no chance of success. And remember, it’s never too late. Your projects may be underway and you may not be able to instantaneously alter your entire corporate culture but starting on support from senior management will help to deliver the rest of the structure over time.

Selling Project Management to Management or… Why is this so hard?

It is a lament I hear almost every week. “How can I convince my management that we need to implement more project management?”

It’s not universal, of course, but the number of organizations where executive level support for the project control environment is either non-existent or openly negative is remarkable. Even more remarkable is that these same organizations often have executive level commitment or interest in better managed projects. What is it about implementing project control that makes executives so reluctant to take it on?

The issues break down into several categories:

By far the most significant category is a lack of understanding. Even with the advent of desktop project management systems such as Microsoft Project, the science of project management is complex and not grasped instantaneously. Part of the project is that project management and project management systems have become synonymous with project scheduling and project scheduling can be an involved subject. Network flow diagrams, Critical path scheduling, arcane terms such as “Total Float” or “Lag” make the subject even more daunting. Acronym such as “BCWS” don’t make it any easier for those people whose involvement in the actual workings of the project management process will be cursory at best. (By the way, BCWS stands for Budgeted Cost of Work Scheduled or, “the budget”).

Is the answer to this education? Special classes to train managers in how to calculate the Critical Path of a project? I think not. Why a manager should know all these terms is somewhat beyond me. In almost no cases will this make the person a better manager. Management’s input into the project management process is not to analyze the intricacies of a detailed project schedule.

To compound this problem, a second favourite category is the complaint of many project managers and schedulers is that on the subject of project management their own executives seem to have the attention span of a gnat! Decisions that, for a project scheduler involve detailed consideration of reams of data simply do not interest executives. In fact, the most common request by executives of their project managers is for single-page reports.

This problem can best be seen in public service. A cabinet-level politician or bureaucrat is so inundated with the day-to-day details of their department that they are often given no more than several minutes on a monthly basis in order to make momentous decisions on multi-million or multi-billion dollar projects. It is not that these people are not interested, just that this is the amount of time available for this type of decision at this level. I’ve seen several situations where this level of government official is given 3-5 minutes to give a go/no-go decision on continuing or cancelling a project worth well over $100million. To the project manager or scheduler, this lack of executive attention must be unbearably curt. Yet it is as common in the private sector as the public.

A solution? More time you say? I’m afraid not. Even doubling the amount of time spent at this level will still result in a ridiculously short amount of time spent analyzing the data. The problem is a difference in perspective.

Yet the demand in the executive suite for more effective management of projects is intense. Economic pressures increase the need for even more efficiency every day. For those executives or management teams struggling to understand what they must do in order to implement such systems, other differences in perspective continue to make selling project management to management difficult.

One of these differences in perspective is the notion that choosing the right software will solve the problem. The combined world-wide marketing efforts of the project management software hype-meisters leaves promises of effortless “enterprise-wide” project management on the pages of almost every major computer publication in existence. (Yes, I know, I’ve been guilty of this myself). With the current craze for ERP systems, and Office Suites which include project management functionality, this kind of promise is held out to executives as the holy grail of solutions to their woes.

Does this mean that software will make no difference? Of course not. But software is only one aspect of a solution and, in my experience, software implementations which occur in a vacuum devoid of management support, process changes, cultural consideration and a commitment to change inevitably result in failure. No, software alone does not solve this problem.

If you have been tasked to sell project management to your own executive or, if you are part of an executive and wondering why you should be interested, here are a few factors to consider:

· First and foremost, distinguish the perspective of the players involved. It is inappropriate to think that the interests of an executive responsible for the outcome of dozens or hundreds of projects and for the overall viability of an organization are identical to the interest of a project scheduler responsible for bringing several projects on time and on budget. This means that whatever presentations, reports, analyses, meetings and so on, must be tailored to who is involved. I’ve done hundreds of presentations on our own project control timesheet software and almost always have someone from the executive level of the firm in attendance. But I almost never have that person attend the entire presentation. We organize the agenda and schedule of the presentation so that the executives can attend the section most appropriate to them and leave if they wish (They almost always do) before starting the “nuts and bolts” of how the software works. Executive briefings almost never last more than an hour.
· Next, organize regular project management reports and presentations for management with the knowledge that there will be never be an understanding of the arcane terms and science of project scheduling and project cost control. Remove references to such items from your reports. If your project management software is incapable of doing things like renaming terms like “Late Start” to “Projected Finish”, start thinking about new software. In this case, less really is more. Keep your reports to a page or less and, if you must, keep a 2^nd level detail in reserve to back up your analysis.
· Third, apply project management principles to your project of selling project management to management. Can I say this enough? The most infrequent users of project management are project managers on their own projects! How does this apply here? It doesn’t take much imagination. Define clear goals, get a project sponsor, set a timetable…you know the rest.
· Don’t be enthralled by the notion that the purchase of any one piece of software will instantly and completely solve all of your project management problems. The implementation of software is sometimes a perfect time to effect a culture change. Sneaking in a new paradigm of behaviour on the back of a project control system is a favourite technique of mine.

You’ve got to look at the whole project control process whenever you’re interested in improving the effectiveness of project management. If you’re interested in selling project management to your own management, start with identifying management’s role in the process. Where do they fit, what is their contribution and what impact will that contribution make to the enterprise? A request for input when that input will clearly make a direct difference to the outcome of something is irresistible to almost everyone.

Managing IT Projects in a Sea of Change

If the world would just slow down for a minute, maybe we could get something done. The biggest problem with IT projects is that nothing in the project is ever stable. In other industries, there are elements which are stable enough that they can be counted on for the duration of the project. Carpentry skills and carpentry tools have had very few changes in years. Yet, in a major IT project, almost every significant aspect of the project is likely to change during the execution of the project.

The design that never ends
Over the 12-24 months that a major IT project is likely to take, many elements are likely to change. The design of the target application itself is almost always impossible to close.

In a commercial application, choosing the target functionality is often driven by a combination of factors including feedback from current clients, beta test users and focus groups. The target platforms may be different both from a hardware and software perspective. Imagine how many applications in the last two years have had major platform target changes as marketing directors run into the development department and declare that unless it’s in-the-cloud-enabled there’s no point in writing it.

In an internal system, the demands of the client change as they watch the world change around them. Thanks to the Internet, never before in the history of this industry have so many people had so much access to so much information about software. While the IT department is trying to pin down the exact requirements, users at virtually any level of the organization can find similar commercial applications or articles about such applications on their Web browser.

Hardware changes
Only a few years ago it seemed quite reasonable to amortize PC hardware over a 3 year period. Accounting firms still have formulas for amortizing PCs over a five year period (I’m not kidding, I ran into this only last week). As everyone knows, computer hardware is obsolete almost before it’s delivered. Over an 18 month period, the hardware that the project started on is invariably not the hardware it will be installed on. Since most users are changing their hardware to be larger, faster and better, this is not often a critical concern. Where it can become a problem is where hardware is upgraded with the programmers first and the software then only works with their hardware.

Operating System Changes
The switch over from Client Windows applications to browser based was a traumatic experience for most developers which not everyone has recovered from yet. Whenever a new version of an operating system is released and users across the enterprise begin to upgrade, programmers suddenly find themselves scrambling for compatibility. Any operating/system-provided layer becomes an issue. This includes data connectivity such display based modules.

Programming Platform Changes
While everything else is being changed, the language itself that the development is being done in is changing also. We suffered a 60 day delay in a new version of one of our projects earlier this year when our development environment got a new upgrade which we deemed essential to fixing some known problems but that required a re-write of our installation scripts and a whole new testing cycle. This kind of thing can happen all the time and it needs to ba managed.

Database upgrades
With so many IT projects now counting on commercially supplied databases, any upgrade to these products can have a dramatic effect. Do the drivers exist from all other parts of the project in order to connect properly to this database. Should you be reverse compatible with earlier versions? Should you not upgrade and risk not getting the new features and, worse, the fixes that are surely in this version?

Third party products
If your environment depends on any third party products, then the problem is compounded geometrically for each third party product that’s included.

Remember, everything needs to come together at one time. The operating system needs to be compatible with the hardware (noticed the PCs that have “We’re not quite ready for that version of Windows” notices?). The database needs to have the features requied to support the project and needs to have drivers which can be accessed by the hardware, operation system, programming environment and third part tools. The third party tools need to be compatible with the hardware, operating system, programming environment and database. The programming tools need to have the drivers for all of the other components working simultaneously. Finally, the design needs to be something that can be delivered by the tools selected in the first place.

It’s a wonder that the combination ever turns out but when one element changes, all the others might have to as well.

If you’re managing a major IT project keeping the ship moving in this sea of potential mines is no trivial task. Still, there are some things you can do and some methods of operating which can mitigate the risk.

For hardware changes the biggest problem comes when the developers have their hardware upgraded first and then the software is written to fit inside their premium sized boxes. When the application is deployed smaller terminals suddenly need to be upgraded in order to function with the new software. One of the ways to mitigate this risk is through the QA process early on in development. Let the programmers write and compile software on the fastest machine in the building, but make them test it on the slowest. There’s nothing like making a programmer stare at a slow screen to give them incentive to speed things up.

For operating system changes, the best recommendation is “go slow”. Each change, even when it seems minor needs to be tested in the field. And every change can have a cascading effect. In our office for example we found that testing the last release of Windows wouldn’t support some of our older but still perfectly functioning monitors. Rather than upgrade these machines, we’ve left them on earlier versions of Windows until the monitors can be upgraded or the hardware retired. The cost of upgrading hardware in order to make the latest operating system work can be prohibitive so it’s not to be taken trivially. Make sure when the project starts just where the client operating systems can reasonably be expected to be over the coming year and write to the lowest common denominator.

For a programming platform the problems can be more severe. If fixes inside the programming platform mean that an upgrade is required, then run a test development platform to ensure your existing code will port to the new version. Earlier this year we were obliged to move to an upgraded programming environment only to find that some of our existing code had run afoul of an unreported bug in the new version. Since the new version was not 100% backward compatible for this particular feature, we were obliged to spend several days writing work-arounds for the code. If you’re sure you can upgrade the development environment successfully, assess the effort required, if any, to upgrade essential components to legacy users in the field. Your other option is to continue with the older version for some time with work-arounds where required.

Database upgrades are something to also take on with some caution. Database providers are also regularly upgrading existing versions and releasing new ones. One experience we had recently had us move to an upgraded version of a database product which fixed several minor problems and threw a much more terrible one at us which we had to struggle with. If possible, patches, upgrades and, in particular, new versions should be run first on a mirror testing site to ensure they won’t cause any problems. In particular the availability of new drivers for all the other components is often not assured. Ideally, choose a database platform at the beginning of the project and stick with it until the first version is released, make an upgrade to the database coincide with a new version of the application.

For third party products, the rule is use the fewest sources possible. If third party products are essential to the application then access to the source code is likely something that should be considered. The worst case scenario is that a small third-party supplier goes out of business just before the application can be released leaving you with outstanding technical problems, no upgrade path and no support.

Finally the most ephemeral aspect of any IT project, the design. I’d love to tell you to firm up the design before you start, carve it in stone and bring it like Moses down from the mountain to be seen by all but it’s just not realistic. With a world that changes as fast as ours does, the chances that even the best written design specs (and most of them aren’t) could survive the 18 months or so the project will last are almost nil. The best way we’ve found to mitigate this risk is to modularize the design. ITIL processes have come to adopt this kind of thinking. IT projects are almost always design/build projects anyway. (This means the building will be going on while designing is still occurring). If you can modularize the coding of the system by function and then use basic good programming practices for standards like object classes (dialog boxes, field types etc) then tossing functionality in or out of the design becomes much more palatable. Around here we often say “it’s better to look integrated than be integrated” and if only for the design problem alone this is very true.

Regardless of whether your project is a commercial or internal application, working in a sea of change makes the project risky. Keep yourself open to change when it occurs but if you’re to be successful, start working on the first day of the project on contingency plans to mitigate the risk.

Projectizing your business

It was once a dark art. Those of us who practiced it were considered no less than fortune tellers, connected somehow to the supernatural, performing our strange rituals of calculations which once seemed no less outlandish than the science of alchemy seems now. When we were done we would create colourful displays of our results, showing that this project or that would now end 2 months earlier or 2 months later and there was no one present who could say otherwise.

Times have changed. Now project management methodology is taught as part of all management curriculums. Critical path calculations, barcharts and activity network diagrams are now as common as finance reports. Managing by project has become one of the hottest new trends in today’s management circles. It seems that everyone is doing it. There’s lots of incentive. The last 15 years has seen a period of rapid increases in efficiency in IT thanks in part to the drive for project management during the Y2K period. A more global economy and startling improvements in communications have allowed companies all over the world to compete for even the smallest amounts of business. No matter what industry you’re in, you’ve got to be able to deliver short product runs, be able to survive on the slimmest of profit margins, be as efficient as possible.

This trend towards management by project has allowed organizations of all sizes to compete on a more level playing field. Even a small organization can deliver an efficient project. But what does it take to manage an organization by project? Is it a new software choice?

The short answer is no. Projectizing a business starts with a structure change.

Most organizations have grown up as organizationally structured. If it was a family business to start with the most common structure is hierarchical. A family head at the top, vice-presidents below, department heads below that and so on. Even once the family is no longer involved, the basic structure will carry forward on its own momentum in a top-down structure. Fifty years ago, this was virtually the only management methodology.

Some organizations start in a more structured fashion or grow from hierarchical management environments to accommodate much larger companies. These groups may become more of a matrix organization. In a matrix, some managers are responsible for managing the departments, while others are responsible for getting work through the system.

A completely projectized organization would have no responsibility with a department. All responsibility would rest with the project managers.

Each of these methodologies has benefits and drawbacks, but they’re each worth considering for the advantages in efficiency they bring.

A hierarchical organization is typically able to change very quickly. Once the top tier of the company is convinced that change is required, others in the organization are informed and are expected to comply. The big disadvantage of course, is that any input from the lower levels of the organization which might have been useful is never considered. Also, if a change in management results in a less commanding presence than is expected, the entire organization might suffer (I’m sure I’m not the first person to wonder what Microsoft will be like once Bill retires).

In a matrix organization, there is a benefit of dividing responsibilities and, hopefully, getting more input from more management personnel. The department managers are typically responsible for the training, availability, hiring/firing etc. of their staff. They provide an expert-level service for work to be accomplished. The project managers use those services by requesting personnel for particular projects. They’re responsible for delivering the project. The downside to a matrix organization is the inherent conflict within the organization it creates. Perhaps in a perfect world this would be the most effective but in some companies, the pull of some managers to try to retain as much authority as possible makes the structure a breeding ground for upset. In a multi-project environment, some project managers will complain that their project isn’t getting a high enough priority for resources. Some department managers will complain that the project managers are “hoarding” their people. There is certainly more maintenance to the structure in a matrix environment.

In a project environment, there is the benefits that come from single-mindedness, concentrating on the project and its deliverables. The downside to this structure is the lack of belonging. Personnel wonder what will become of them once the project is completed and this sometimes leads to personnel ongoingly looking for work. Also, there is little allowance in this structure to take the lessons learned from one project and apply it to the next. This type of structure is most commonly found in mega-projects or in organizations which have been formed for the express purpose of completing a particular project.

Over the past few years, more and more companies have been leaning towards giving more authority to the project management aspect of their business. There is a desire from many CEOs to at least be able to track the company by project if not manage all personnel that way.

From a systems perspective this can be a huge challenge. An organization whose systems were built up over a period of years to collect, analyze and report data in one type of structure are often less capable of delivering the same types of results for another. Accounting systems, scheduling systems, payroll, even timesheet systems are structured to the needs seen by their developers at the time.

If you are in an organization which has determined that it is changing its basic management structure and you are responsible for some aspect of that change, you are likely going to have to deal with some systems issues.

Start by identifying what you are doing now and which data systems and reports are going to be altered. Sometimes this identification is very simple. Management might, for example, have made a new request that from now on, labour and materials costs will be reported project-by-project. Sometimes you’ll need to dig a little deeper.

Next start looking at how you will be able to collect that data by project rather than just by department. Don’t drop what’s working already! If you’re currently collecting timesheets from the department manager for instance, don’t assume automatically that you’ll now collect them by project manager and that the department manager will be dropped from the loop. What you’ll probably find is that there is some requirement from both sides to have access to that data.

When you start to implement your changes, go slow. Start with one aspect of the total structure. Wholesale changes all done in a single moment are almost always destructive. Make your small change and see how it affects the rest of the company. You may find that for some period of time, you’ve got to do double entry to take care of both aspects of the business. Grin and bear it. Keeping what’s working operational for awhile is great insurance against issues you may not have considered in the new structure.

You can continue to implement area by area following this kind of plan until you’ve reached a level which is comfortable for the entire organization. It’s entirely likely that this level is well before a fully projectized organization yet is much more projectized than you are already.

To help stabilize that structure, one of the more important things to do is to determine that new systems and new packages being considered and implemented will have the project-oriented functionality required for future moves in this direction. This is particularly important if, like many organizations, you are in the middle of replacing your core financial and management systems to become Y2K compliant.

The perfect balance for a particular organization is probably a balance between these structures and each organization must determine for itself which way to go. Changing software itself might make you projectize-able, but it’s going to require a change in management structure to make you projectized.

Dealing with the Project Server 2010 technology stack

It’s called “The Stack” over at Microsoft. It refers to the layers of technology that are required to get the Microsoft EPM functional. For those who only have experience with Project Desktop this will sound unfamiliar. After all, what’s to know? You put the DVD in the box, you hear a whirring sound. When it’s over the DVD pops out and you start entering tasks in Project.

If only Project Server were that simple.

Microsoft made the decision years ago to leverage the different technologies that Microsoft produces for its server products. When we’re asked to deploy the Microsoft EPM “Solution” for Project 2007, here are the Microsoft Products we need to think about:

Windows Server
Internet Information Services (IIS)
Active Directory
SQL Server
SQL OLAP Services
SQL Reporting Services
Microsoft Office
SharePoint Services (WSS) or Microsoft Office SharePoint Server (MOSS)
Project Professional
Project Server
Project Web Access (PWA CALs)
Portfolio Server
Portfolio CALs

That’s pretty much been the list since Project Server was first introduced and later when Portfolio Server was introduced. With Project 2010, we know the list will change a little:

Windows Server
Internet Information Services (IIS)
Active Directory
Exchange Server
SQL Server
SQL OLAP Services
SQL Reporting Services
Microsoft Office
Microsoft Office SharePoint Server (MOSS) 2010 is now required
Project Professional
Project Server
Project Web Access (PWA CALs)

At first glance the list doesn’t seem that different. The Portfolio Server license is now woven into Project Server and a new option for Exchange Server is added. But, let’s take a peek below the hood.

In Project 2010 you will need MOSS. The Project team is leveraging technology available only in MOSS so it’s not an option and the option to use Windows SharePoint Services is discontinued. Ok, that may have an impact on your licenses or perhaps not but lets think about the impllications.

SharePoint is the fastest growing server product in Microsoft’s history. A large number of organizations have adopted the platform in its 2007 incarnation. Let’s imagine that you’ve *just* finished deploying SharePoint 2007 and now Microsoft comes along to explain how great Project Server 2010 will be. But, in order to take advantage of Project Server 2010, you had to adopt “the Stack”. That means you’ll need to upgrade your SharePoint from 2007 to 2010. That may be quite a challenge. You might have extensive customizaiton in SharePoint 2007 that would have to be migrated. You might have applications that only work with SharePoint 2007 and not yet with SharePoint 2010 or that might have to be upgraded themselves to work with the new SharePoint.

Only a version ago, Project Server was viewed as the vanguard; the product that would “pull-through” technologies like SharePoint into the organization. Now, however, that same link may have organizations think twice about going to the new technology because of the platform they’ve adopted.

Interestlingly I had a conversation about this just last week with my friends at Occam who have been doing Project Server hosting for years. Hosting the new technology might be an attractive solution for many project offices who are keen for the new technology. It has been attractive for a minority of users thus far, but if going to a hosted model eliminates the challenge of confronting “the Stack” then it may well be attractive when Project Server 2010 hits the streets next year.

Have you seen Simon Moore’s new book?

Moore_SPPM I was delighted to see the release recently of my friend Simon Moore’s book Strategic Project Portfolio Management and proud as can be to see my review of it on the jacket. I’ve known Simon for years. He’s one of the smartest people at Microsoft and he’s been in a unique position to see how organizations choose projects and, more interestingly to me, how they implement systems to help them choose projects.

It’s nice to see a book out of a Microsoft colleague that’s not just a how-to for Microsoft products. Simon focuses on the process of choosing projects and how senior management has to take part in the process.

Take a peek. The book is available from Amazon. If you’d like to see some of the other things I’ve been reading, take a look at our Book Recommendations page.

Integrate or Interface?

integrate “Sometimes it’s better to look integrated than be integrated.” It’s a saying that goes back a few years now and I can’t even remember who coined the phrase first. I do think about the concept from time to time though. It seems most appropriate in meetings such as the one I had last week where a senior IT executive asked me to comment on a 15 page data flow diagram showing how a legacy timekeeping system would be integrated with the system we had recently supplied.

Fields were mapped representing data in both systems, stored procedures were referred to but not defined. The understanding of how data was to move back and forth between the systems was sketchy at best. What was perhaps most unclear was what benefits were expected to be realized by the organization through this extensive amount of work.

This is not an isolated case. In our work implementing project control environments we’ve had plenty of opportunity to look at extensive ERP implementations where months of effort are allocated for “interfacing” which typically refers to full integration of data between multiple usually non-compatible systems.

What is it that makes this kind of exercise so compelling? Well, it makes for great marketing hype. If you’re in the business of selling man hours for implementing enterprise systems, then this scenario is made in heaven for you. Pretty PowerPoint slides showing lines of data moving between all these systems and suggesting that management will be able to get completely integrated data are enthralling. Not long ago I watched a demonstration showing a financial report on screen which, with a click of a button, dissolved into a pie chart. From there to a histogram and a click on the histogram and the graph broke into a spreadsheet showing multiple suppliers. One more click and this list became another graph and from there down to an individual invoice. To say that this demonstration got the attention of the potential client would be an understatement. These executives were virtually salivating, imagining an ultimate level of control of their own organization’s data.

The truth is not always so easy. In practice, data must often be approved and batched together before analysis. There usually needs to be a defined flow of data from one place to the next and, if as is almost always the case, this data will come from multiple systems which may or may not (probably not) have been designed to integrate their data together.

As I’ve often said in these pages, the most effective analysis of such decisions is one where the Return on Investment is measured. A demonstration which seems delightful is not enough reason to start integrating systems which must be done at an architectural level.

In the 15-page data flow diagram I recently had to confront, data moved from one system to the next, other elements moved back to the first and more elements again moved back to the second. It was difficult even to follow the logic. This might have been worthwhile if there had been some measurable benefit but if there were big gains in efficiency to be found, I certainly couldn’t recognize them. The legacy system was, of course still there but the initial impetus for integrating the two systems seems to have been for the purpose of producing a single report which would show total hours across departments.

Even if such a report had been required it would have taken the tiniest fraction of effort to import the data from the legacy system into the new system in order to produce the report. “Ahh, but that would require intervention every single month,” I was told. “Good point,” is my reply. “However, the 15 minutes it would have taken every month is by far less than the 4 weeks spent writing the integrated design and code and the countless hours spent trying to keep the systems in synch!

Interfaces have another hidden benefit as well. Having to intervene to create the interface is a perfect point of control to manage the data flow. If you’ve got a checklist item in your procedures which says “import the timesheet actuals” then having to physically click an icon or select a menu option and to ensure that it runs is a great place to make sure that item is complete and that all data has move from the source system to the transaction file and from the transaction file to the receiving system as required.

Many finance departments have this in their periscope already. Many systems promote their “open architecture” database as the holy grail of systems integration. There’s no doubt that an open architecture provides more options than a closed architecture but the picture painted is often too close for comfort for finance people. Finance systems are, after all, tough to get stable and once stable, there is a tremendous reluctance to touch them even for upgrades. Every time I’ve suggested that we’d be prepared to intimately integrate the data from a project control system into the accounting system directly, the finance staff have stared at me in horror. No, they say, it would be far preferable to deliver a “transaction file” to finance for importing when they’re darned well good and ready. The idea that an “external” system (for Finance, this mostly means anything outside the GL, AR, AP, PR package) would change cost values in the main accounting system without human intervention is abhorrent to most finance personnel.

While this is true for the systems we’ve been implementing, in many cases it will be equally appropriate for other internal systems to follow the same logic. When an interface can deliver the result at a fraction of the investment of time and effort, then you’ve got to take a careful look at what it’s providing. Far better to interface systems in an organized fashion than to spend the next 6 months trying to determine why the “integrated” system isn’t.

Archive: November 28, 2009