Project Planning - need some advice please

[Solarion]

I've not had to plan any kind of project in maybe many years, I usually just get stuck in and do a bit of research then get coding.

Do you guys do this too or do you use gantt charts, flow diagrams etc? If so please could you give me a few pointers. I have to start somewhere in learning the other half of the business.

TIA

 

[Spacerat]

Depending on the size, but definately process flow diagrams and use case diagrams

 

[spiderz]

Clear requirements ...

 

[John_Phoenix]

A clear spec per module(usually markdown), uml diagrams and a flow chart to turn it all into a view at 30,000ft. Then if there is enough time, data flow maps and schemas throughout the app.

When speccing out something guard against feature/spec creep, or it'll sink a project faster than the titanic.

For frontend, it's even easier,
Wireframe -> design -> critique ->
build alpha -> test -> augment to beta -> test with as much real users/data as possible -> finalise -> launch!

If you are solo in this endeavour, remember to only wear one hat at a time, Unix single responsibility extends to planning too.

 

[Solarion]

Thanks guys much appreciated.

 

[Barbarian Conan]

It depends on the methodology. For waterfall a gantt chart helps, assuming you are pretty good at estimating how long implementing a feature will take.


Then I like a sequence diagram for multi-tier applications, UX diagram for the front end, and depending on how serious people are about the UI, a visual design doc.
On some projects we've even built a static html demo app that's used as the spec.

I have not used UML since graduating, but I can see the value for larger teams.

 

[envo]

I don't start coding until the database design is finalized, which gives me a nice diagram of what it's going to look like, and a nice overview of if this will fit the needs for the project and specification.

But that's assuming you have some sort of specification.

GANTT and Flow Charts are just project manager type stuff for meetings. Oh look. Our SPI is 1.2, we so awesome *strokes themselves*

The flow charts of any UI type design, especially if you work with Tester's, will be very helpful for them. "Click here then this happens then click there to make that happen" etc. Also gives you team an idea of the flow, but it can be very basic.

 

[LOTR]

Must start with very clear user/business requirements. i.e. what the user expects to see or expects the system to do when you insert/click "A" , "B", "C", etc. Include error messages and exception handling while you're about it.
Have a clear list of Business Rules.
Any form of flow or sequence diagram (Workflow/UML/whatever - depends on project size and methodology used) always makes it easier to spot errors and missed items/requirements.

Ensure that any assumptions and decisions are agreed upon and documented. (Saves on issues later). Also document potential risks on assumptions and decisions made.

If the change has an effect on screens/UI, mock-ups will greatly help non techie types to understand the flow/process.
If methodology/stakeholders requires it, then a project plan/Gantt charts will assist. I prefer planning from the left (i.e. no fixed delivery date), but if you have a fixed delivery date, then Planning from the Right is essential (i.e. is there enough time available to complete by due date). Assuming you are able to get realistic effort estimations based on provided requirements.

Per envo above if a new database or a change to existing db is required, get the design finalised before coding starts.
Update all stakeholders at least weekly as to progress, escalate any new blockers/risks/issues immediately.
If infrastructure changes are required (e.g. new server), ensure that funding/procurement is initiated and approved early.

Set up demo's to "show-off" work in progress/pieces of work completed, especially where UI is largely affected (show the "wow" factor if applicable). This is a great way to get user agreement or issues/changes earlier in the project.

Beware of scope creep and changing requirements. Don't refuse them, just consider the consequences resultant therefrom.

Monitor approved budget and spend. Don't build the Ferrari when a Mini will meet all requirements.

 

[Spacerat]

A good way to assess scope and functional breadth & complexity is to do functional decomposition. It's a fancy term for breaking down the system functionality into smaller bits. If a block is too high level with too many unknowns, then break it down more. Until every block is sufficiently defined and of low enough complexity to estimate properly in terms of effort and time. Because the functions have been have down to manageable size, it becomes easier to estimate. The decomposition is very important, because the devil is always in the detail. If you feel a function is still too nebulous, keep asking the customer questions around the function. Invariable some more detail will pop out and you can expand.

Use cases are a great way to communicate this. So let's say the app requires user management. So we can assume we know what user management is all about and put one use case down to indicate that the admin will do user management.

Like this:


But there is more. User Management is too high-level, so we break it down to a typical CRUD type activity:


But there is more. The user (and admin) must have a way to reset his password:



Woah, by chatting to the customer it turns out that the users have to use a mobile device like this http://www.datalogic.com/eng/products/healthcare-retail-other-solutions/mobile-computers/memor-x3-pd-636.html out in the field. Entering a pass in gonna be ****ty. So we decide that users must have a numeric PIN as well so that it can easily be entered on the device keypad. Also PIN reset. So the use cases expand once again.


I tend to not use Word for my requirements as typing and formatting gets in the way of my 'creative flow'. I use Enterprise Architect from Sparx to do all my documentation. ERD, Use cases, process flows, the lot. And it is pretty cheap. The diagramming environment is smooth and you don't have to worry about formatting. The actors, entities and relationships all live within the UML model. Therefore the diagrams are not standalone diagrams. They are actually views into the entire model. These diagrams literally took 2 minutes.

Then as part of a typical use case I would then create a screen mockup of the screen that the user would use to perform that function. I only do that where the UX might be more complex. I use Balsamiq for this. Again, the environment is such that your creative flow is not interrupted. The screen mockup captures the essence of the UX for that function. That then feeds into the design of the ViewModel in code....

 

[Pho3nix]

Very nice software @Spacerat. Whats the code importer/export tool they talk about?

 

[Solarion]

Very nice software @Spacerat. Whats the code importer/export tool they talk about?

I would give him more rep but it won't allow me. Pretty awesome stuff there yes. Sorry I am lurking just crazy busy atm.

 

[SYNERGY]

A clear spec per module(usually markdown), uml diagrams and a flow chart to turn it all into a view at 30,000ft. Then if there is enough time, data flow maps and schemas throughout the app.

When speccing out something guard against feature/spec creep, or it'll sink a project faster than the titanic.

For frontend, it's even easier,
Wireframe -> design -> critique ->
build alpha -> test -> augment to beta -> test with as much real users/data as possible -> finalise -> launch!

If you are solo in this endeavour, remember to only wear one hat at a time, Unix single responsibility extends to planning too.

Star Citizen is the perfect example of the above.

 

[Spacerat]

Very nice software @Spacerat. Whats the code importer/export tool they talk about?

Well EA can generate source for you, or reverse engineer (import) source. In its simplest form, given a class definition in EA, you tell it what the language is then it will generate the source file for the class. Don't really use it, but just played around. Similarly for reverse engineer a source file(s), it will create the class definition in the EA model. Similarly for ERD and tables.

I actually wrote some tools around EA (the automation interface) and Word. So I have toolbars and buttons in Word that automatically inserts the open diagram in EA into Word. Also dumps the diagram elements and notes into a table. Dumps table definitions into a Word table. Very useful for making the Word-EA collaboration very productive.

Also created some EA plugins that, from a table definition in an ERD, creates the template based table and view script, as well as the C# class definitions for my ORM.

This is what EF can do as well. But I prefer absolutely all documentation for a project in one place. And its ERD diagrams are very powerful

 

[Pho3nix]

Well EA can generate source for you, or reverse engineer (import) source. In its simplest form, given a class definition in EA, you tell it what the language is then it will generate the source file for the class. Don't really use it, but just played around. Similarly for reverse engineer a source file(s), it will create the class definition in the EA model. Similarly for ERD and tables.

I actually wrote some tools around EA (the automation interface) and Word. So I have toolbars and buttons in Word that automatically inserts the open diagram in EA into Word. Also dumps the diagram elements and notes into a table. Dumps table definitions into a Word table. Very useful for making the Word-EA collaboration very productive.

Also created some EA plugins that, from a table definition in an ERD, creates the template based table and view script, as well as the C# class definitions for my ORM.

This is what EF can do as well. But I prefer absolutely all documentation for a project in one place. And its ERD diagrams are very powerful

Thanks for sharing!