There is one problem with word Vision I have casually thrown. It drags with it all these grandiose thoughts about creating great things that would really make a difference etc. I hope we shall stay clear of that.
I red the document I had downloaded from PMI website (thank you Chris). OK, I red most of it. Nevertheless, I found it quite useful, since it would allow us to avoid bickering around basic definitions (like: what a project is?). Some problems however remain and we have to answer them ourselves. Below I list the ones I found essential (fill free to add or remove something from the list). I shall also propose an answer to each of them. These answers should quite accurately describe my vision of our endeavour.
1. Intended audience: software developers (in broad meaning of the term) or maybe any group assembled in order to participate in a temporary endeavour undertaken to create a unique product or service.
2. Are we going to create a tool forcing people to work in a given way (for example, use one of methodologies that software development realm is littered with) or we provide a generic tool allowing people to assign scarce resources to tasks, synchronize tasks in time etc regardless what the resources and tasks are.
3. What is the path we choose build a grand opus, after careful planning and meticulous and lengthy programming or rather release something simple but useful soon.
4. Should the software facilitate whole project management planning, progress tracing, communication between members, distribution of electronic resources etc. or maybe just a part of it (the best guess would be planning + progress tracing).
It is easy to notice 1 and 2 overlap (if we are making program for everyone, we cannot apply some profession specific magic incantations).
Now my answer:
We should intend a project to be for everyone and approach project management as something generic, which does not depend on particular field. We will be biased towards software engineering anyway and besides, initially we will offer program to software people.
So what basically we want to do is to create a program that will help to schedule tasks (which may or may not be interdependent), assign resources to these tasks etc and tasks to people or teams (I keep founding the notion that people are just a resource a bit offensive ;-)). A resource can be limited or unlimited, available all the time or not etc. Than the program would help in managing the project by supporting communication between team members and by making it easy to trace progress.
I think, we should design a small thing first say generic planning and tracking, with some basic diagrams and reports. That will allow us to see, whether someone is really going to use it. If yes, we should add the thingy with communication (it is really an awesome idea). The other good idea next stage for development could be adding profession specific templates you know, once we have basic (simple yet powerful) engine, we can talk to people in their own jargon. The downside is, that the only template that we would be able to offer would be software development but if someone else would help us who knows???
In short my idea for start is: we ought to create simple and generic program for project planning and tracing. Lets release it soon and create some interest in it. It is supposed to be simple, but we need to put some cool and unique features in it - to distinct ourselves from all the other folk outh there. We should put them in requirements as soon as we agree on some vision and action plan.
What do you think?
Regards,
Marcin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Once the question for vision is answered, and I disagree that you should keep away from it. It is a good thing in that you don't HAVE to implement the vision all in one step, but it serve as a beacon of the long term goals.
Another interesting factor in this is that whatever is decided, the group should consider working it as a bootstrap to Projectile. If it won't work for the project, it won't work for the user.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't mean, we should avoid having a vision or setting long term goals. I merely stress the importance of adopting iterative approach and setting realistic short term goals.
The idea with bootstrapping is a sound one. From certain moment (well, from first beta, I guess) we should start eating our own dog food.
Marcin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that we will be as much testers for Projectile as developers. If functionality will not serve us then we may not need it (unless it is for some other industry and they need it).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, I forgot about one important matter. Chris, I believe it was you, who wrote the summary that attracted some of us here (myself included).
What do you mean by "built in distributed manner"? I think, this is an important element of the whole idea, I completely omitted in my previous message. Could you clarify this?
Regards,
Marcin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I meant by "distributed" is that Projectile could be a three-tier system. I thought that there would be a GUI or web front end, a middle tier (where most functionality would exist) and then a relational database. If a user or admin could not reach the server then the project could be saved as a XML file for later upload. We need to keep the mobile user in mind. I would suggest that we look at Interbase (www.interbase.com) since it is a great database and soon to be open sourced. I think also that corba would be smart as the middle piece. Maybe I said "distributed" when I should have said "n-tier". We can change that later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have some thoughts on the architecture, so not one noted for keeping my opinions to myself, here goes ;)
The database should be independant of the code. In this way different databases can be used if required. One obvious way is to make a bunch of data read/write functions. These can then be replaced with database specific ones if someboday wants to use it.
Somebody mentioned interbase as a DB candidate. Never used it but I'm willing to give it a go.
I think the underlying communication mechanism should be Corba. This solves a few platform issues, also allows the service to be hosted on one machine and the GUI on another, also allows for a web front end if somebody builds the server CGI/ASP/PHP process to talk to the engine.
For data representation I think XML is definately the way forward. It easily allows data to be passed into/out of of DB access methods. Also it provides a way (kind of) of extensability.
The front end I am completely open on. Somebody mentioned wxPython, but I think we are still too far away to really worry on this one.
I totally agree we should start to design/model the basic entites/features (<-- insert favourite buzzword here) etc
If nobody gets to it earlier, I'll knock something up on the plane this weekend.
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
There is one problem with word Vision I have casually thrown. It drags with it all these grandiose thoughts about creating great things that would really make a difference etc. I hope we shall stay clear of that.
I red the document I had downloaded from PMI website (thank you Chris). OK, I red most of it. Nevertheless, I found it quite useful, since it would allow us to avoid bickering around basic definitions (like: what a project is?). Some problems however remain and we have to answer them ourselves. Below I list the ones I found essential (fill free to add or remove something from the list). I shall also propose an answer to each of them. These answers should quite accurately describe my vision of our endeavour.
1. Intended audience: software developers (in broad meaning of the term) or maybe any group assembled in order to participate in a temporary endeavour undertaken to create a unique product or service.
2. Are we going to create a tool forcing people to work in a given way (for example, use one of methodologies that software development realm is littered with) or we provide a generic tool allowing people to assign scarce resources to tasks, synchronize tasks in time etc regardless what the resources and tasks are.
3. What is the path we choose build a grand opus, after careful planning and meticulous and lengthy programming or rather release something simple but useful soon.
4. Should the software facilitate whole project management planning, progress tracing, communication between members, distribution of electronic resources etc. or maybe just a part of it (the best guess would be planning + progress tracing).
It is easy to notice 1 and 2 overlap (if we are making program for everyone, we cannot apply some profession specific magic incantations).
Now my answer:
We should intend a project to be for everyone and approach project management as something generic, which does not depend on particular field. We will be biased towards software engineering anyway and besides, initially we will offer program to software people.
So what basically we want to do is to create a program that will help to schedule tasks (which may or may not be interdependent), assign resources to these tasks etc and tasks to people or teams (I keep founding the notion that people are just a resource a bit offensive ;-)). A resource can be limited or unlimited, available all the time or not etc. Than the program would help in managing the project by supporting communication between team members and by making it easy to trace progress.
I think, we should design a small thing first say generic planning and tracking, with some basic diagrams and reports. That will allow us to see, whether someone is really going to use it. If yes, we should add the thingy with communication (it is really an awesome idea). The other good idea next stage for development could be adding profession specific templates you know, once we have basic (simple yet powerful) engine, we can talk to people in their own jargon. The downside is, that the only template that we would be able to offer would be software development but if someone else would help us who knows???
In short my idea for start is: we ought to create simple and generic program for project planning and tracing. Lets release it soon and create some interest in it. It is supposed to be simple, but we need to put some cool and unique features in it - to distinct ourselves from all the other folk outh there. We should put them in requirements as soon as we agree on some vision and action plan.
What do you think?
Regards,
Marcin
My 0.02
Once the question for vision is answered, and I disagree that you should keep away from it. It is a good thing in that you don't HAVE to implement the vision all in one step, but it serve as a beacon of the long term goals.
Another interesting factor in this is that whatever is decided, the group should consider working it as a bootstrap to Projectile. If it won't work for the project, it won't work for the user.
I didn't mean, we should avoid having a vision or setting long term goals. I merely stress the importance of adopting iterative approach and setting realistic short term goals.
The idea with bootstrapping is a sound one. From certain moment (well, from first beta, I guess) we should start eating our own dog food.
Marcin
I agree that we will be as much testers for Projectile as developers. If functionality will not serve us then we may not need it (unless it is for some other industry and they need it).
Oops, I forgot about one important matter. Chris, I believe it was you, who wrote the summary that attracted some of us here (myself included).
What do you mean by "built in distributed manner"? I think, this is an important element of the whole idea, I completely omitted in my previous message. Could you clarify this?
Regards,
Marcin
What I meant by "distributed" is that Projectile could be a three-tier system. I thought that there would be a GUI or web front end, a middle tier (where most functionality would exist) and then a relational database. If a user or admin could not reach the server then the project could be saved as a XML file for later upload. We need to keep the mobile user in mind. I would suggest that we look at Interbase (www.interbase.com) since it is a great database and soon to be open sourced. I think also that corba would be smart as the middle piece. Maybe I said "distributed" when I should have said "n-tier". We can change that later.
I think that it is very important for us to begin the core of our system. XML, Corba, Database... It is not very important for the moment.
In fact, we may use DB API generic then choice of database may come after.
XML or Corba are useful when our core will communicate with GUI, with others softwares, with some plugins ( optimizer schedule, ...) ...
Then, What entities must be created for this core system ?
Ressource, Project, SubProject, Budget, Planning ?
I am not very efficient to create model in UML, but I think it a good beginning for this project. Who want to begin it ?
Didier Rano
I have some thoughts on the architecture, so not one noted for keeping my opinions to myself, here goes ;)
The database should be independant of the code. In this way different databases can be used if required. One obvious way is to make a bunch of data read/write functions. These can then be replaced with database specific ones if someboday wants to use it.
Somebody mentioned interbase as a DB candidate. Never used it but I'm willing to give it a go.
I think the underlying communication mechanism should be Corba. This solves a few platform issues, also allows the service to be hosted on one machine and the GUI on another, also allows for a web front end if somebody builds the server CGI/ASP/PHP process to talk to the engine.
For data representation I think XML is definately the way forward. It easily allows data to be passed into/out of of DB access methods. Also it provides a way (kind of) of extensability.
The front end I am completely open on. Somebody mentioned wxPython, but I think we are still too far away to really worry on this one.
I totally agree we should start to design/model the basic entites/features (<-- insert favourite buzzword here) etc
If nobody gets to it earlier, I'll knock something up on the plane this weekend.
Simon