A long time ago, in a lifetime far far away, a client asked me to help their PMO produce useful project plans. Never one to turn away a job, I agreed to speak with him and review the documents his team produced. Leafing though the packet, I found the same things I always find in project plans - lack of coherent planning, no focus on document purpose, and a very limited control of how tasks interact to create workable processes.

The good news, I assured my client, was that he had a lot of company in his situation. The better news was that it’s not that difficult to get out of the psychological rut which leads project managers to create useless project plans, post them, then ignore the hoary artifact in favor of more mutable spreedsheets or calendars.

I prescribed him a simple remedy - four questions I always ask myself before I sit down to wok on a project plan. These questions are as follows.

1) What do you want this project plan to do?

My client’s eye’s crossed when I gave him the first question. “A project plan organizes project work in a reportable fashion” he mumbled, trying to understand what the frak I was saying.

A project plan is, when we get right down to it, a document. Documents exist for a variety of reasons. We use them to record information, to communicate information to one or more audiences, to brainstorm possibilities, or as records of exercises undertaken to understand a problem to name just a few.

The first step to creating a “useful” project plan is to figure out what, in a given context, we need the project plan to convey in order for it to be useful. A project plan written to satisfy auditors must meet very specific criteria which might not have anything to do with actually running a project. A project plan written to aid executive reporting might not contain the information an auditor wants, just as one written to help the project manager actually track multiple interwoven sites will read differently than any of the above.

Trying to write a project plan to cover all “whats” generally leaves the author with a confused, useless mess. Not unlike what I find in organizations all over the country.

2) Who will use this project plan?

My client’s suspicions raised even further when I showed him this one. “Didn’t we answer that in the first question?”

Well, yes and no. When we asked the first question we defined a use and an audience. In this question, we try to dig down and figure out who will interact with the project plan and in what ways. Some of this is contextual. In one organization the PMO may dictate that developers always create and update their own tasks, while another may put all the weight onto the project manager’s shoulders.

I generally create a chart when I try to answer this question. In the first column I put roles and/or names if I know them. In the second column I put in how I expect them to interact with the project plan. In the third I put in how frequently they will interact with it.

3) What will the project plan contain?

“Ummm…” my client said. “Don’t project plans contain tasks, dates, and precursor information?”

By this time, he had pretty much figured out my standard “yes but” answer. Yes, a project plan by convention contains all those things.

However, the real question is what tasks? How do we filter and vet the vast amounts of process information required to run a project into a useful document based on what we need it for and who will interact with it? Do we just drop everything into the project plan and hope someone will get around to updating it? Do we use a very minimalistic, critical path kind of approach. If we do the later, how do we determine what needs to be in the project plan and what doesn’t?

I wish I had a handy trick for making this filter. Unfortunately, this is one of those “technique=time+context+person” things. How we build the filter depends entirely on the answers to the previous two questions along with a host of other process related variables. This is why, I suppose, we have consultants.

4) Why is the project plan important?
“Okay. I get the first three. But this is…” I thought I would cut to the chase, because it looked like my client was about to get a headache.

Every document can be important in at least two contexts - the author’s and the reader’s. It’s vitally important to differentiate between the two, otherwise we end up with yet another confused mess involving poor communication and broken expectations.

For an author, the act of writing the document is often sufficient to organize his thoughts and allow him to move forward. He may never have to revisit the document again to gain benefits from it. We generally call this a success, especially if we see a positive improvement in the author’s productivity or development.

For a given reader, the document is only successful if it meets his expectations about what information he will find. To use this blog as an example, if I titled this article “How to make a great cake”, my gentle readers would justifiably want to flog me. For a project plan, we have to know why a reader feels the document might be important to him. Then, and only then, can we hope to meet his expectations.

Each author can with a little bit of work uncover his own motivations. Uncovering the why of a document in a corporate setting can become unwarrentedly challenging due to politics, lack of focus, and compromises which the author might know nothing about. This situation unfortunately dooms the fledgling project manager, but that’s just the way the world works sometimes.

5) What is deadline of project plan? 

if project plan does't contains exactly defined deadline date, how project manager can maintain the project. Typacaly project plan are writen without final date. Then developer said when i hasn't deadline I will make 

this future tomorrow, why now. In the last week everyone in company fast to complete his tasks, because they all are for last time. If exist project plan with strong defined dates, this problem don't appearance.

Introduction

Currently, Object-Relational mapping is probably the hottest topic of discussion on the internet in terms of the various software development circles. With all the hype surrounding ORM, it is easy to forget the why?. Why does ORM exist? It would seem that ORM has become somewhat of a religious war. One can only wonder if the ORM war will have people in the future asking a why? The focus of Object-Relational mapping is to solve the object-relational impedance mismatch. I.e. the object model does not equal the relational model and this is considered by many to be a problem. There are those that have subscribed to the viability of ORM as a persistence strategy, and there are those that have not. Some have questioned whether the object-relational impedance mismatch is a problem at all. Others argue that the object-relational impedance mismatch issue is being solved on the wrong side of the equation. I.e. there are those that advocate the use of Object-Oriented databases as a solution and not ORM. The fact that ORM has created so much attention and heated debate implies that there is something of importance or at least perceived importance. I leave it up to you to decide. That something deserves a closer inspection to separate the hype from the fact. The aim of this article is to encompass important a view for and against ORM. By so doing, it is intended to establish a different, or at least more informed, perception of ORM regardless of what the current perception may be.

Intent

To be fair, the topic of Object-Relational Mapping requires a book to address all the matters relating to it in its entirety. I provide just enough information in this article to allow one to consider ORM from a pragmatic perspective.

Object-Relational Mapping as a persistence strategy is both a statement and a question. In the first instance, I am implying that ORM is a persistence strategy. In other words, ORM is a viable technology in terms of satisfying ones persistence requirements. In the second instance, I am questioning ORM as a persistence strategy. I.e. Is ORM a viable solution in terms of satisfying ones persistence requirements. The focus of this article is not on the best ORM tools that are available. Best is at best transient and what is best today may not be whats best tomorrow. Instead, the focus is on ORM at a conceptual level. The reason that I have chosen to focus my attention at a conceptual level is due to the nature of change. ORM tools will appear, change, disappear and reappear. Technology will evolve and so will ORM tools. I consider the concepts behind ORM to be of far more significance and value. This allows one to view ORM in a pragmatic and hopefully unbiased view. Therefore, the intent of this article is to view ORM at a conceptual level, in an unbiased manner, and assume a technology agnostic approach.

For the purpose of clarity, the intent of this article is further summarized to be as follows:

• Description of ORM
  • What is ORM?
  • Why does it exist?
  • In what form does it exist?
  • What are the problems associated with ORM?

• Viability of ORM as a persistence strategy
  • Discussion on the requirements of a persistence strategy. Determining how well if at all ORM satisfies persistence requirements.
  • Reusability
  • Maturity
  • Time and Cost
  • Architecture

• Choosing an ORM
  • Commercial vs. Open Source vs. In-house

• Succeeding with ORM

Failing with ORM

Object-Relational Mapping

Often, a good way of understanding what something does, is to understand the reason for its existence. I.e. why does it exist? In terms of enterprise software development, most if not all software systems deal with getting data in and out of a data store. In this context the form of data store is unimportant. What is important is how one deals with the data store persistence. Data persistence implies the concept of persisting and retrieving data. It is a common and recurring development challenge. For those that are familiar with design patterns, the aforementioned statement should sound oddly familiar. Design patterns, at their simplest definition, are tried and tested solutions to common and recurring challenges. Therefore, is there or are there design patterns to deal with data persistence. Yes, there are many patterns that one might employ to deal with the data persistence challenge. Is ORM such a design pattern? ORM may use many design patterns to achieve its end. Whether it in and of itself is a pattern is probably a discussion best left to another article or forum. ORM is a technique that one might choose as a data persistence strategy. ORM is a solution, not the solution. It does help address a common development challenge, that being of data persistence. The popular term to describe the data persistence issue is that of the object-relational impedance mismatch. The question that arises is whether the impedance mismatch is really an issue. The Java development community seems to have adopted ORM well before any of the other development communities. I used the word seem as I have not encountered all development communities and therefore cannot say with certainty that this is the case. The Microsoft development community has chosen to ignore the object-relational mismatch until recently. I say recently because there only seems to be a boom in terms of the availability of ORM tools in recent times. I am not, however, implying that Microsoft has chosen to ignore the mismatch issue. Before continuing the discussion of ORM, the following points are highlighted in terms of understanding the definition of ORM.

• It provides a way to resolve the object-relational impedance mismatch. This object-relational impedance mismatch is considered to be the core problem.
• It is a technique for converting data between a relational database and an object-oriented programming language
• It is an abstraction of data persistence code
• The result of an ORM implementation is often likened to that of a virtual object database.
• ORM provides us with database independence 

To further elaborate on what ORM is, I discuss ORM in terms of the following challenges:

• Core Challenge
• Conceptual Challenge
• Legacy Challenge
• Usability Challenge