I'm trying to find a way to propose a project for our company, and I've never done that before, within a year of work, but have lots of plans/projects in mind to do things automatically.

Sometimes, I would go beyond the norms of the company (whenever I have free time or at home, I would create an app). Creating a simple application that would take about two weeks to program. However, I see myself losing traction and motivation because of lack of support to finish the project, thus losing motivation to present them. (It is hard to get it done).

I've been thinking that in order to have the correct motivation, the company I'm working for should support the project first, then create the application after approval.

In the back of my head, I would also think that the users would just end up not using the app, although I think it could be easier to use the application for efficient communication, but even for just small reasons (like another reason for the user to memorize a username and password to login), it can end to the lack of participation in using the app, leaving the project unsuccessful.

I have learned project management in school, but have not really seen anybody perform the task successfully from point A to point B. Is there any effective steps that I can follow from successful project managers out there?

What tools do I need to consider in each step for effectivity?


  • Will you be using this tool yourself to perform your job and, if so, does it help you perform your job faster? Sep 29 '15 at 23:42

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 application can have, and is willing to spend some time and money to help you make it happen. Even if you do all the development for free, there is a cost of rolling out a system and supporting it.

Because of that, you are correct to believe that you should have the support first, then build it. That said, company cultures vary and some may really appreciate the initiative of you going above and beyond.

You will also need to have a way to determine if the project was successful. Getting code into prod doesn't mean a thing if the app doesn't fix the issue from the business case. Maybe you want 50% of the users using the app within 3 weeks of cut, and 80% by 5 weeks.

Create milestones. These are things that you expect to happen by specific dates (e.g. Design signed off by Sept 12, Code complete by Oct 19, User acceptance signoff Nov 3, etc.) Milestones help keep you on track and help with motivation.

You will need to work with someone to get the app into production, and figure out who will be supporting the app once it's there. It's a common thing in small shops for the developer to end up being support, and this turns into trouble because it's an additional task on top of your workload. Larger shops will have an AM team who may take it on after a reasonable warranty period, and they get a proper knowledge transfer.

Getting users to use a new system can be tricky. How resistant to change are the users? How much training will be required? Does it make their jobs any easier? Having good communication with the stakeholders can smooth this road considerably.

  • 2
    The business case should prove a positive NPV that is greater than NPV's of other options that could be invested in. The project should do more than create revenue or solve an existing problem. Investing in the project should be presented as the best decision the investor can make.
    – WBW
    Sep 14 '15 at 22:48
  • While your comment is technically correct, I'm not sure it's relevant here. This is a project the OP wants to do on their own time, so from their standpoint it already has passed that hurdle. If anyone needs to do NPV it would be the sponsor. Mar 28 '19 at 13:17

I stumbled upon a role doing this kind of work rather naturally; except mine was VBA for excel spreadsheets.
You are correct that first you will need others to buy in to your apps. The problem is that the people using the apps really need to define the problem it is remedying. If the users define the problem then they will be gung-ho in supporting you. I have tried to push apps on people and have found no success in this tactic.
This started for me when I started making macros to speed up my own work. Then some people asked questions and I'd consult my macro. Then I got questions like "What is that?", "How'd you do that?" This exposed them to my skill and rather slowly people started asking for stuff. At this point you can start suggesting ideas for apps.
As far as managing the project, this depends on how long it may take to develop. If it is a short project (2-3weeks) I'd use some agile technique with a kanban board. If it's longer then I'd make a Gantt chart. Key for both methods is to break the project into smaller steps and give yourself twice as long to complete each task than you think it will take.

Just be sure to keep your boss informed and included in any work you do for other coworkers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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