Its common for most software development processes to begin with a plan of attack, in which you could find the following topics:

  1. The context of the clients company
  2. A summary of the business processes to be improved
  3. The current state of business (regarding that which is to be automated)
  4. A clear description of the task at hand
  5. The project activities
  6. The scope of the project
  7. The planning
  8. The products to be delivered
  9. The projects risks and the efforts to minimise the impact.

Currently I'm making my plan of attack. I'm wondering if the information stated above is enough or if it is better to include more information in this plan.

My question to you all is, what do you think of the mentioning of the above topics into the plan of attack, what information would you describe and what are the expectations which you would have should you be in the role of an customer or of a project member?

  • We have no way of evaluating whether it's "enough" for your use case. Why don't you tell us whether you feel the steps you have will give you enough information to work on your project? If not, why not?
    – Todd A. Jacobs
    Commented Aug 26, 2013 at 15:58
  • The project is my first formal project, i have already plan which contain the above mentioned. I was wondering if it is enough since the project is in a learning context there is no real client that's the reason why i wanted experienced people to give their view on what should be in a plan of attack and what shouldn't. Commented Aug 26, 2013 at 16:16
  • 2
    You may wish to research the concept of a "project charter"; there are multiple examples on the internet. It appears that you're trying to re-invent the PMI project management phases. Although not everybody loves them, I think it is an error to ignore them.
    – MCW
    Commented Aug 26, 2013 at 16:37

3 Answers 3


I agree with Mark on the project charter artifact. It essentially sets up a project. However, regarding plans in general, if you can answer the who, what, where, when, why, and how, you have a plan. No matter if you are still in strategy phase or driving down to the tactical, those question must be answered and answered in way that another person can grab and go. Anything else to add (that is not a decomposed topic of these basic questions) is icing on the cake.

  • I don't know if I can formulate a "where" question for project planning, other than a resource question like "Do we have a place to stick the team or store our widgets?" I (obviously) agree with your premise, but I would love to see a practical example of a where planning question.
    – Todd A. Jacobs
    Commented Aug 26, 2013 at 18:15
  • Your examples are exactly that. Where is the work being conducted? Where do the raw materials need to go? Where do I store this artifact? Where do I find xxx or yyy? Commented Aug 26, 2013 at 18:40


You are inventing your own terms for common project management artifacts. What you are describing is commonly known as a Project Charter or Project Mandate, although some methodologies may use other terms for this type of output from project initialization.

If your organization doesn't define a process for this already, then ask your stakeholders what level of detail they need. No one outside the organization can make that determination for you.

Formal Methods of Project Initiation

One source describes two of the formal methods for documenting Project Initiation, citing examples from the PMBOK and PRINCE2. It even includes Project Charter and Project Mandate templates.

These templates aren't necessarily canonical, but they certainly provide useful examples. You can use your own checklist and format if they serve your needs better.

The Essentials

Regardless of your methodology, a project initiation document ought to cover the following essentials:

  • What is the goal of the project?
  • When does the project need to be complete?
  • Who is involved in the project?
  • How will you measure the success or failure of the project?

Other items like budget, resources, scope, and so forth are really additional levels of detail that drill down into the foregoing. It's up to the organization and the project manager to determine what level of detail is required to define the project.


And before the First Day there was Nothing.

Then the Executive Team looked upon the Nothingness and said “Lo, this is not good as our competitiveness is at risk.”

And so on the First Day the Sponsor developed his Mandate and gave it to his Champion and Project Manager to make right.

And on the Second Day the Champion and Project Manager did work with the Executive Team to identify those Key Stakeholders that must be consulted. And they gazed upon this list and said “This will do at this stage”.

And with the close of the Third Day the Champion and Project Manager did facilitate a discussion amongst the Key Stakeholders to identify the Vision, which begat identification of Wants and Needs. And the Wants were summarily turfed as too costly, but the Needs were kept as they were necessary.

On the Fourth Day the Needs were developed into a Project Product Description, such that everyone could agree on what was to be built and a general Project Approach and could estimate Costs and Resources and Schedule at a Very High Level in a Summary Business Case delivered to the Executive Team on the Fifth Day.

And the Executive Team said “We might have something here”

And with this approval upon the Sixth Day a more detailed investigation of the Project Products, its Costs and Benefits began, to the point that planning for the project, including definition of Scope, Budget, Resources, Schedule, Risk, Contracting, Benefits, Communications, Governance and Quality could be initiated.

And then, on the Seventh Day, the real work began….

  • Heh. I'm trying to decide whether to upvote this. I really like it (very well-written, Doug!) but I'm not sure that it directly answers the OP's question. It does a good job of describing the political process of creating a Project Charter, but I understood the OP's question to be more about a specific artifact. --If nothing else, you need to blog this somewhere. It's great!
    – Todd A. Jacobs
    Commented Aug 26, 2013 at 18:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.