Programing experiments

About project management

It has been 10 years I have been working as a programmer. In this 10 years I had a “proper” project manager only twice. When I started and now. Unfortunately when I started some of the project manager were in position of power (compare to my position) and behaved more as commander than … “project manager”. Which alienated this position to me.

Now the project manager is quite good and I benefit from many years of experience. And I’m observing intently. And I want to clarify what is this project management thing. Because, I suspect, it might be useful! smile_teeth

And maybe I’d like to be project manager too oneday, if only for financial reason! smile_wink


As I can see it now, the good project manager, in his role as project manager, has the following responsibility: clarify the project’s goals, and schedule everyone’s work so that we all progress smoothly at a regular pace, satisfy customer expectation (for deadline and feature) AND satisfy developer expectation (for implementation strategies).

It doesn’t even need to be the architect. For example in our case, since we use prism, WPF, MVVM and other technologies (which, I’m glad to say, I was quite instrumental in bringing and doing the core implementation) our project quite naturally divide itself into some simple uncoupled part (Save for one service which we have identified as needing further simplification) and there isn’t much architecture or need for it happening now. We just expand on our current model.


Anyway, what is our good project manager doing (name is Patrick Kealy by the way)?
Well, mostly, he is writing down in great detail our many discussion and using Microsoft project to schedule everyone’s tasks to the day (approximately). Which is harder than it seems… The end result when he comes with our tasks for the next few days, is that it all seems simple and easy!

Better, if someone raise an issue (I’m good at raising issue by the way! smile_tongue) we talk about it. If there is clear criteria for something, we act on it. If it takes too much time, we put it down on the schedule so that the deadlines are still met, but so that the developer knows that his concern will be addressed (after release v0.xxx). I think this is very important for an harmonious, hence productive, work environment.

In a few words, it’s not so much about deciding what to do, but more about making clear what we decided and propose an efficient roadmap.


I think his work has provided some focus to Agdat (which was erring somehow in random direction before he started). And now the application starts to looks like something!

It’s late now, so I will just put a yummy screenshot:


Categories: General
Permalink | Comments (2) | Post RSSRSS comment feed
blog comments powered by Disqus