8

The issue is not just that documentation was poor, rather that some of your planning deliverables were either not done or not implemented. Documentation in and of itself won't help you. That being said, documentation provides evidence that your team has thought through what you need to do and has developed a reasonable, feasible and achievable plan. The key ...


7

First thing, you need a business case. The project must either solve an existing problem, or be something that can create revenue. "This will be really cool!" is not generally considered a business case, but if you work at a place where it is, all the better. You also need to get a sponsor. Someone in the company that can see the value that this ...


6

Is it worth to apply any of the project management techniques? Whether a one-person team or more, applying project management principles will always help because it provides a way to measure project status and visibility into the actual progress. However the level of processes application may vary, that is, various PM processes can be carried out with less ...


5

Notwithstanding how you were supposed to get paid by the client, you need to have the best interests of your client in mind. This means you need to inform your client of your inability to resolve the issue and make a recommendation to your client to either find another solution provider or to abandon the solution because maybe there might not be an ...


5

One project, multiple epics I don't really see how 25+ epics will be more chaotic than 25+ projects. Don't overthink things. Redeveloping a monolith application into a micro-services architecture will be challenging enough for your team, they shouldn't also be forced to analyze things from an organizational point of view to see where each task goes where. ...


4

I think Kanban may work best in your environment. And with some people being remote, you're almost forced to use an online Kanban board. I'll try to address the two issues you raise one by one. Global View You can maintain a Global View of the multiple projects by: Having all projects on the same board, and indicate with a color what project the task ...


4

You don't try to handle everything up front or predict the future. It's a waste of time and effort. As you build out the software and get stakeholder feedback, you will learn more about the true needs of the stakeholders. I'd recommend looking at the techniques of Agile Data and Agile Modeling. These two sets of practices can help you apply and integrate ...


3

My background is similar, so I'll tell you my lessons learned. To get started, let people know you are interested in the PM role, and that you would like to work as a project admin or coordinator to get some experience. These are roles where you get to see a lot of the management activities but for the most part you don't have a lot of responsibility for ...


3

I'd start by moving to a physical task board. Tools can be great force multipliers. However if you start in a tool, you will often get influenced by the tool and end up doing process by tool. This is happening to my teams at AOL now and I've got teams experimenting with physical task boards for day to day and Jira just to document the work for official ...


3

I've found that "scrum" can mean very different things to different people. To me what differentiates it from other agile processes is the focus on commitment based sprints. Since you have not listed delivering sprint based deliverables as an important benefit for these projects you might get more value out of other lightweight agile processes rather that ...


3

Coming from a similar sized company within the software development industry, producing similar IT projects for clients ranging from 2-6 months builds I have a good understanding where you're coming from. It sounds like you have good processes in place for managing your projects, which includes documentation processes, however the problem that I'm hearing is ...


3

You are looking at this incorrectly. A document itself is only as valuable as the paper on which it is written. Like the risk log, for example, folks will typically labor over the log so it is almost museum quality and forget they are supposed to be navigating rough waters. Documentation is nothing more than 1) evidence that some type of planning took ...


3

Welcome to the community! As Vadim mentioned in his comment, your question is a little complex, so I'm going to try and break it down into bitesize chunks. We use it more as a todo list than a real project management system. First off, strictly speaking, Kanban is not a project management system or methodology. Kanban is a framework, or a set of ...


3

Why don't you get them to plan out their educational careers? There is a huge amount of potential for them to: Articulate a vision of where they want to be in 5-10 years Develop a business case to justify spending Mum's $$ on their education Identify soft as well as hard benefits and costs Identify stakeholders that they need to engage (Mum, profs, future ...


3

When I signed up for the course "Project Management", honestly, I didn't expect too much. Thing is, I attended similar courses before and most of them were just boring. I mean, theory is nice and good, but you don't believe it until you get some hands on experience. People are like that and it's good, though sometimes annoying for the teachers ;) Anyways, ...


3

Aziz has a great answer, but I would not skip risk management just because it is a small project or you're on your own. When you have the What and the When cleared out, take some time to reflect upon the impedements that you will encounter along the way. This doesn't have to take much time (in fact, it is a continuous process) and it will probably help you ...


3

Even if you dont want to apply any of the Project management techniques, you will end up using a few of them. Decision regarding which technique to use largely depends on type of work you would be doing and team you would have. Also the schedule that you would follow would play important role. Regarding tools: I have seen people managing projects ...


3

Whether or not it is 'normal' is highly subjective and contextual. What is more important is whether or not it is a problem (which I assume it is, otherwise why are you here asking about it?), and, if so, how to fix it. The problem you have is that of clients asking for last-minute amendments. This can be broken down into two sub-problems: 1) The client is ...


3

The "Project Coordinator" Role Titles can and do vary widely in the industry and around the world, so you are unlikely to find a canonical answer. However, in the US industries I've worked in, the role you're describing is often termed a Project Coordinator. One source describes the role of Project Coordinator as follows: While the specific role of the ...


2

I had a similar situation when I left a small start-up a couple of jobs ago. While I wanted to help them out as they transitioned my replacement, I also wanted to prevent them from overly relying on me. The solution I came up with was to set up a consulting contract with them. The key things included in this were: A reasonable hourly fee that didn't ...


2

MS Project (or similar tools) is good for to schedule management related PM activities,e.g.: highlight and visualise relationships (prerequisites etc.) track delays and identify the consequences Having (at least) those two capabilities it might help you to track and prioritise your activities. I can't imagine what to do with grades within MS Project ...


2

Start small, and don't try to overcomplicate the process. Try using a tool like Trello and organize your tasks with a simple Kanban style workflow. Setup some simple lists like: Blocked Backlog In Process Testing Client Review Done


2

The value of Scrum starts with a dev. team of minimum 3 people and is actually felt from 5 people onward. If you are the only developer, I would not bother with Scrum, you can get inspiration from it, but really it boils down to a good features prioritisation and personal management.


2

One of the characteristics of a successful project is tailoring the project management methodology to the project's criticality and complexity. So don't ask "Do I have enough?", ask "Do I have what I need?". To figure out if you have what you need where you are the only team member, talk to the end customer(s)/user(s) and find out what is important to them....


2

Seems like you need to add a periodic activity to your management called integration. Once a day/week/month you need to all sit together and figure out when you need each other- and for how long, and schedule accordingly. A set of sticky-notes on a wall - one lane per person - is all you need for tracking.


2

Lean on the basics of project management. You have a list of tasks that need to get done and they vary in complexity and effort. Some of them will take a while, some will be short and fast and easy to do. Break down those tasks as far as you can to capture all of the things that are required for the overall task to be done. To measure your progress and ...


2

Sounds like it's just a way of teacher's teaching style. They seem to imply, in basic terms, any non-repetitive task can be called a project. In the book's case, from what the question includes, finding the cause of the problem and learning the details of the problem is the first project and solving the problem is the second one. On the other hand, if ...


2

All tasks are projects. If you start to plan "Fix the problem", you're going to fail. If the problem is "Someone has unplugged the server", the WBS is going to be short, the quality tests are clear, etc. If on the other hand, the problem is "The server uses code that relies on a windows 98 library, and the programmer who maintains that library just ...


2

I see two broad approaches to solving this issue. One Agile, one not. The "non-Agile" approach is to hire a lawyer and have your contracts drafted in such a way that the burden of miscommunicated requirements falls on the vendor (freelancer) instead of the customer (you). The downside of this approach is that few experienced freelancers will bother to ...


2

I hope your two partners never see this post. There's so much more to make a product successful in a fickle market than building product...especially a prototype. There are a host of other knowledge and skill sets required to move a product through its natural lifecycle and to yield a profit, that you likely do not have or that they have more than you or ...


Only top voted, non community-wiki answers of a minimum length are eligible