6

Many a time I get lost in the middle of a project, and the project gets delayed. I have four projects which are still not completed, and new projects are coming.

How should I approach a new project? Are there any books or websites that help understand what I need to do first?

Do we make a database or static design first, as the customer wants to see something online after booking the domain? What are the steps to take when starting a new project?

What we do at our end is start with static designs, then start with the database, and then do the coding in ASP.NET.

Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270
Moksha
  • 1,030
  • 6
  • 17
  • 38

5 Answers5

5

You have multiple projects going on, and you need to pick up a new project... well, let's take a step back and look at this from the high level.

Projects A B C D unfinished. What are their statuses? Are they on time? If they aren't, how did they get behind? How they got behind, will it happen to your new project? Do you have the resources to finish these projects on time? Do you have the resources to finish these projects at all?

Project E to be started: Do you have the resources to finish it? Even start it? Do you know what the end result needs to be? Do you know the intermediate steps to get there?

Do you have help internally, both above and below you? What assistance can these people offer?

You need to answer these questions, or at least most of them. These are the questions that help project management. Time - resources - talent - know what you have and what you need!

Without more specifics, I can't really help you more.

corsiKa
  • 81,495
  • 25
  • 153
  • 204
5

Chapter 3 of David Allen’s book ‘Getting Things Done’ outlines a great approach to project planning.

It’s not specific to software projects, and it’s very light on methodology, but I’ve found it really useful when planning projects. At that middle stage when you’re getting lost, it’s useful to look back to this planning process to see where your problem is, and thus how to solve it.

I’d urge you to read the chapter (and chapter 10, which has practical suggestions on how to implement the approach), but if you want a slightly shorter and less well-written summary:

  • “Projects” are desired outcomes that require more than one step to achieve them.

  • The “natural” (i.e. best suited to our brains) way to plan projects is:

    1. Define purpose and principles

      What’s the project trying to achieve? (Purpose.) What standards and policies should we satisfy whilst trying to achieve the objective? (Principles.)

      With client work, it’s usually up to the client to decide the purpose, and at least some of the principles. However, they may not have though about it themselves, so you may well need to listen to them carefully from the outset, read between the lines, and figure out what will help them. Thinking about the purpose of a project can stop you getting stuck on a particular task — you may realise the task isn’t even necessary to achieve the purpose.

      You may well have some principles that you like to adhere to (e.g. your idea of “clean code”), but remember the client probably has theirs too (e.g. getting IT projects done quickly), and they’re the ones writing the cheques.

    2. Envision the outcome

      What would success look like?

      This can involve high-level outcomes (e.g. the client’s staff enter 20% more orders per day thanks to your OrderTron.NET Enterprise Edition CX) and more specific definitions like a spec — which is where I imagine your static designs come in.

      All of this lets you know what you’re aiming for, and thus helps you figure out how long it will be before you’re done.

    3. Brainstorm

      How can we achieve the outcome?

      Once you’ve got a clear idea of what success would look like, your brain will, almost without your control, start generating ideas about how to get there. Allen suggests noting all these down, without judging whether they’re good ideas or not, to take advantage of your brain’s creativity.

    4. Organize

      Right, how can we actually achieve the outcome?

      Now that you’ve got ideas about how to achieve the outcome, you organise them into a plan. Split the project up into components (e.g. database, validation, user interface), figure out priorities (e.g. the user interface has to support IE 6), and map out sequences (e.g. the data model will need to be fleshed out before we can start design the interface).

      You’ll be doing this repeatedly throughout the project.

    5. Identify next actions

      What can I do?

      Now that you’ve got an organised project plan, what’s the next physical action that can be done to move the project forward?

      There will probably be lots, and they’ll probably be tiny, e.g. create a folder for the project in our source control repository, do a first draft of the data model, Google ASP.NET validation).

      Once you’ve got some next actions, that’s enough planning for now. Do them. You’ve now got a plan to come back to when things need reorganising.

Although I’ve listed these in order, you’ll move through all the stages lots of times during a project. For example, nitty gritty implementation details (5) can force you to redefine the successful outcome of the project (2) given the principle of keeping costs limited (1), or brainstorm new implementation approaches (3), which leads to you reorganising who works on which modules (4).

Also, this process applies to really large projects (e.g. implement an order entry system for a client) and really small “projects” that are part of a large project (e.g. implement the validation layer for the order entry page of the order entry system). Whenever you’re lost in the middle of a project, check that for whatever bit you’re working on that you know what the purpose is, and what the outcome should look like.

If you’re vague on the outcome, figure it out in more detail. Refer to the spec. Ask colleagues. Google. Etc.

Take heart. None of this is easy. An approach like Allen’s is good to help stop you getting lost, but the skills you use at each stage of the approach can only be learned by years of hard work, mistakes and experience. If you’re having trouble figuring out whether to do the database first or not, you might just need more actual programming practice.

But the fact that you’re thinking and asking about how to do projects better means you’re already doing more than lots of people ever do. Good on you, and best of luck.

Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270
1

There are books and web-sites beyond one's ability to count to answer your question, in brief and in depth and for all manner of projects. I suggest you read the responses to your question here, but check Amazon and Google around. I think that Tom Gilb's book is still one of the best, certainly if you could only afford one book and bought this you wouldn't regret it.

From all the published sources and my many years of project management I distil only one piece of advice:

Stop starting new projects until you learn how to finish old projects.

High Performance Mark
  • 77,191
  • 7
  • 105
  • 161
1

No there is not such book for you*...

You are the professional...and you are the only one that can give the answers. If you don't know what is more important, no book will help you and you are in the wrong job.

Having this said, I wish that there more like you asking for advise... to help you in the time management field where most people need help.

There are many methodologies but if my feelings about your need are right, all you need is two softwares and alot of discipline: MS project(or something similar) excel(or other spreadsheet)

Make a detailed plan - detailed enough to tell you at the end of each day if you fell short or exceeded your plan. But not to detailed - you need time to work and not just toy with dreams and plans for the future.

in the excel make a log: task ! plan hours ! actual hours in days where you accomplish less then 90% of your actual planing - are very hard days with a lot of over time - you want to go to sleep and fix everything tomorrow -don't! Spend an hour to log what went wrong... phone calls, meeting... everything.

You have to problems 1. You don't know to make good estimations. 2. you jump from one task to another loosing valuable setup time.

You will be late in the next project as well and that is unavoidable... but if you will understand where you loose time. You will make more realistic plans and become a better manager.

*If these thumb rules are not enough - the PMI.org has good website, good course, good book and good people with their PM certification- you can find such expert or become one.

But I really believe that when a professional looks at hard data he can make decisions: 1. I can't speak 4 hr with that client everyday without charging him for the time. 2. That task took me way too long - I need to concentrate, next time I'll do that on the weekend after everybody is gone... shut down the cellphone and finish the job in half time

etc...

  • I strongly advice you to find someone that will teach how to use project management correctly, mainly - how to move unfinished work to the future - it's crucial that you will have the real picture of your status and not just have a list of tasks (marked as finished/ not finished) - You will learn alot from analyzing well maintained plan (well not a plan anymore - but actual work!)

Good luck Asaf

Asaf
  • 3,067
  • 11
  • 35
  • 54
0

And just to make sure it doesn’t get lost in my tl;dr answer above, ‘The Design of Design’ by Fred Brooks is a great whole book on the project planning (and execution) process.

It compares IT projects with architecture/construction projects, which works because the author managed IBM’s OS 360 project and the construction of his own beach house.

It discusses design (i.e. creativity and inspiration) as much as project management, but it’s well worth a read for its in-depth discussion of complicated real-world projects that actually happened, and got finished. It’s simultaneously a great discussion of theory and a great discussion of practice.

Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270