-2

I am learning about management and coming from software development I was wondering how I would design a tool to help users manage their software development projects.

When it comes to the data architecture, my idea is to have the following entities (but the proposed solution might or might not follow through with it)

1) Project - a company / division can work on multiple projects.

2) Milestone - each project can, but does not have to have multiple milestones.

3) Requirements - each projects can have multiple requirements. Multiple requirements can be grouped into a milestone.

4) Task - each requirement has one or more tasks created by the developers. Same task can be a part of multiple requirements. A task is set to be done by a single developer within 2-5 days.

5) Subtask / Checkpoint - Each task can have multiple subtasks, each of them to be done within a day. The idea is that tasks could be created with a template (f.e. initial requirement analysis + required time estimation + design and implementation + test 1 + test 2 + documentation).

From this, I'm considering to build a view that shows projects, its requirements and task in a tree structure.

How would you tackle this?

Appreciate your guidance.

  • Software recommendations are out of scope, and solicitations for opinion are likely to be closed as subjective. I'd suggest that you remove the last four paragraphs and then revise. – Mark C. Wallace Aug 1 '19 at 8:27
  • I don't see reasons enough to close the question. Wojciech Orzechowski asks how he should do what he wants to do, as expected. – Tiago Martins Peres 李大仁 Aug 1 '19 at 12:00
  • @TiagoMartinsPeres the only actual questions here (and there are two, so could close as 'too broad') are 'I would love to know your thoughts.' (could close as 'opinion-based') and a software recommendation (could close as 'off-topic'). I'm not seeing a valid question here. Your link is irrelevant because OP is not asking for a tool recommendation. S/he is saying 'I'm thinking of making a tool. Here's what I think it needs. What do you think? Also, give me some tool recommendations.' – Sarov Aug 1 '19 at 13:15
  • 1
    @WojciechOrzechowski So your actual question was 'what is the best way of structuring a software engineering process'? That was not clear to me from your title nor your Question's body. I suggest you consider editing for clarity. – Sarov Aug 1 '19 at 14:02
  • 1
    This is a software architecture or product design question. It isn't on topic for PMSE. I'm not sure this type of question is on topic anywhere on SE, but if there's a site that focuses on product design or application architecture, that would be the place to go. Maybe check out stackexchange.com/sites# and see if there's a site that would fit, and check out their help section. – Todd A. Jacobs Aug 1 '19 at 17:32
1

I am not sure if you are in a product world (software or other) or in IT (applications development/ maintenance) - but irrespective, here is how I would advise you to think of this.

Conventionally (in the traditional waterfall world), all planning happened in terms of projects, which would get funded and staffed. However, depending on corporate/ financial imperatives, it was easy to kill projects - and cause staff turnover.

Lean/ agile thinking encourages you to move away from project thinking to product (or application) thinking - where products/ applications get funded based on their overall longer-term importance in the organization. They provide you a longer-term planning and execution timeline - as well as staffing capability (typically over multiple years) as opposed to projects that can be very short to very long, and not always intentionally! (Software and IT projects are notorious for their horrendous cost, time and scope overruns!)

From an overall planning perspective, think of corporate objectives/ business milestones/OKRs (Org Key Results) at the top of your planning hierarchy. These may be planned for a year broken down into quarters and months. To successfully deliver on these OKRs, an organization must build/ implement/ launch products that help it meet those OKRs.

Think of these Products/ Applications as the key assets that need to be developed/ maintained/ implemented. Teams need to be dedicated to these products - a team should be dedicated to a product (of course a team might manage multiple products, but ideally, a product should not be split between multiple teams as far as possible. Lean/ Agile thought process highly encourages stable, self-organizing teams that can manage how they work and deliver their product deliverables, given a clear and unambiguous priority for those deliverables.

You might also have shared services (special skills teams) such as UI/ UX design, DB, Architects, Documentation, etc - which split their time supporting the dedicated product/ app teams. However, shared services are discouraged as much as possible to reduce dependencies across teams because they reduce the flow of work for any given team. (Imagine a new requirement's development work being held up due to non-availability of the design team). However, it is quite hard to reduce such dependencies to zero in my experience, in any sized organization.

Finally, you then have dev/ maintenance/ implementation work being done in the Lean/ Agile world in either short time buckets of Sprints and Releases, as in Scrum, or in a continuous manner, as in Kanban.

Scrum teams will deliver their product at the end of each Release. Kanban teams will typically build and deliver work continuously on to a staging server as each feature gets built, or each defect gets fixed, and make releases to a production environment or to an external customer.

So, the Sprint and the Release come closest to your project/ milestone definition. A release may take 8-10 weeks (4-5 sprints) or lesser. At our company, we do monthly releases - by teams that follow either Scrum or Kanban. The release cadence really depends on your business context and the cost/ overhead of making and deploying a release. Typical corporate IT may not be willing to take new product releases from an internal or an external (vendor) dev team - because the cost of testing and certifying a software release before it can be deployed into their production environment can be quite high.

The software/ product itself can be functionally decomposed into a Theme --> Epic --> Feature --> User Story hierarchy - those are your Requirements - the actual hierarchy/ nomenclature can vary from company to company. However, typically, each Sprint will complete a certain number of user stories; which roll up to a certain number of Features getting delivered in each Release.

It would be the job of the Product Management/ Product Owner organization to ensure that the Themes, Epics, and Features are identified, prioritized and detailed in time for each dev delivery cycle. And that they are aligned to those OKRs as well. This is typically taken care of between Portfolio Management and Product Management functions in an organization. They would also have some way of tracking "New Ideas" that might typically spawn an investigation leading to a new initiative/ dev effort.

Many Scrum teams create a task-list against each user story - and use those tasks to track their work and effort. However, many Scrum teams are moving away from effort tracking - the tasks simply work to encapsulate a standard process/ workflow they follow to build each user story.

A Kanban team, on the other hand, will typically visualize the workflow on a Kanban Board, where each column represents the next stage of development (value add) - and they track each user story's progress through this workflow. Many teams use both Scrum and Kanban together and may or may not define and track tasks at all.

So, hopefully, that gives you a good picture of what I am trying to communicate :) - and the hierarchy would look like this -

  • Product/ Application -- Themes/ Epics/ Features/ User Stories --- Tasks/ Workflow stages

  • Release --> Sprints

  • Teams -- Dedicated to products/ apps -- Shared services teams

  • Projects/ Milestones (Optional - mostly in project services companies)

A company that is in the business of doing projects (including fixed cost/ fixed price projects might still do the traditional Projects and Milestones - but ideally, they should use the project plan/ milestones at a high level to guide incremental software/ product development, build sufficient feedback loops (sprint/ release demos) so that by the end of the project - and even for each milestone - they are delivering working software/ features - or sometime even documents/ prototypes - that allow the dev team and the customer be on the same page of what the customer needs and what is being built. Many System Integration/ IT Services do this and call it "Hybrid Agile". Of course, such delivery models are possible when there are mature trusting relationships between customer and delivery team/ service provider (or business and IT) - where each side is ready to collaborate and benefit from the flexibility that this model gives them both.

Based on everything you have mentioned, a combination of Portfolio/ Program/ Team level Kanban boards would be your best bet to capture and track all of these. At the team level, teams might use a Scrum or Kanban or Scrumban approach to building and delivering their work. You could have Kanban boards to track new ideas, OKRs, new initiatives, some of which would drill-down to program and team level boards where Epics, Features and User Stories would describe their implementation, while they get grouped into Sprints and Releases for their actual delivery.

Kanban tools are typically not meant for tracking project plans and milestones - so, if you have to do that, you'd need to do that in a traditional project management tools such as MS Project or many others.

For Portfolio Kanban tools, you could consider our tool - SwiftKanban, which has some great Enterprise/ Portfolio Kanban capabilities that match your requirements - or others such as Kanbanize and Leankit which are also very good, besides several others lesser ones such as JIRA Agile/ CA Agile (earlier Rally) and VersionOne.

Hope this helps!

| improve this answer | |
0

As we are considering software development, that's how i would tackle it

ER model for software development management tool

The model is self explanatory but let me add some more information for context.

Job_sites - locations where users can post jobs (for instances, We Work Remotely, Freelancer, ...). This would have attributes such as Job Site URL, Who added to the list.

Jobs - what a potential client wants someone to do. This would have attributes such as Client Name, Job Title, Job Description, Currency, Price.

Client - someone that has one or more jobs. This would have attributes such as Client Type (potential client or existing client), Person Name, Email Address, ...

Project - a job that the client agreed on us taking over. This would have attributes such as Job Name, Project Name, Project Description, Manager, Status, Priority, Estimated Start / End Date.

Resources - workers. People hired to take over the success of clients (Customer Success Managers), to manage projects (Project Managers), ...

To note then you want to manage user's permissions, not everyone needs and wants to see everything.

When it comes to track Activities and Tasks, Jira does a pretty good job. There's the perk they get access to that information though but that's the price for using something that good.

| improve this answer | |
  • Thanks a lot! I used Jira before, it is indeed very good. – Wojciech Orzechowski Aug 1 '19 at 16:02
  • Tasks can have subtasks in that model and milestones and requirements can be seen as attributes of projects. – Tiago Martins Peres 李大仁 Aug 1 '19 at 16:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.