Project Management 101 Introduction to Project Management.

I've given my brain a rest for today on the coding and cramming end, instead I began thinking about the next couple of projects I have in mind. Namely the address book, and another more long term idea I'm mulling over that I believe will be a great labor of love project.

I realized I'm in a good place to start looking at the bigger picture, outside of coding and coding concepts, and start thinking about what software development lifecycles look like. As I suspected before doing my 'rigorous' Googling, there are multiple models one could follow here, each with their pros and cons. This has got my brain churning over the logistics of various projects built for various clients within various team environments and how this might look from the perspective of a code monkey - working on bits and pieces to meet deadlines, and a project manager - putting the jagged pieces together to meet their own deadlines. I've realized that when I eventually make the shift into this field, I want to go in with my eyes on the big picture just as much as on my own tasks. While I haven't yet dug into many resources on this, it's yet another topic of interest to try and pile on to my growing desire for knowledge.

That said, I'm currently in the market for a tidy little piece of software development...software to help me plan and track these ideas and get them off the ground. I'm going in blind here, while taking some of the above in mind, I'm trying not to overwhelm myself with bulky planning software adding yet another layer of learning on top of everything else. The features of the software or software package I need seem simple enough:

-A visual planning apparatus for a design roadmap
-Timeline and task breakdowns able to be built for an individual in mind in lieu of an entire team.
-Feature changes tracking / revision history or some other fancy sort of note taking addon.
-Ease of use, as in really, really easy.

These 'features' will I'm sure have different nomenclatures in the programming community (hey I'm still pretty green to this), but I'm sure I'll connect the dots. Maybe someday I'll write up a review of different types of such software, who knows.

What I don't need, at this moment, is something as complex as SCRUM or some of the SCRUM derivatives. Which seem to have a focus on tasks broken up into teams in a much more dynamic and fast paced environment than I'd be facing for the time being.

To close, I found this tidbit of information I thought worth saving via a reddit thread from one of the previously mentioned subreddits I'm subscribed to.

The original post is a novel question, which seems simple enough, asking for tips on collecting requirements from clients before a project begins. The top comment provides useful insight:

Identify problems. Problems are what you are building a system for. Don't let them make design decisions for you.
Example from today's meeting: the business I work for has indicated that payments of a certain type must not cross fiscal boundaries and if it does it must be broken into two payments, the first ending on the last day of the current fiscal year and the second starting on the first day of the next fiscal year.
This is a design solution. It doesn't tell me the problem. The problem is that the budget allocated to payments of this type is tracked by fiscal and needs to be both communicated to the people receiving the payment and to accounting to consolidate against.
The requirement in this case is two-fold: Allow accounting to see payments by fiscal year for consolidation and to change the output of the system to indicate limits by fiscal.
Their solution would have been: Semi-complicated date math that arbitrarily splits payments across fiscal year boundaries. This is roughly a full two days from a developer to implement then change all the unit tests to expect this result.
The true solution is: Add a column in a report and add a definition to the contract template. This is zero project time because reports and policy/contracting are separate departments not constrained by the project scope. Arguably the work could have already been done by now.
Requirements gathering is asking a question and getting a problem. Design is asking a question and getting a solution. Don't let people who know nothing about the system other than it's use dictate solutions.

 Obvious words, let's hope I don't loose sight of them.