8

I can think of only one reason why you would inform and alter the schedule of one supplier when another is late: dependency, in which case you would have integrated the schedules and everyone involved will see the variances and impacts accordingly. All projects produce variances. A variance free schedule is a fake one. I cannot imagine trying to ...


8

I recommend: Demonstrate your application to the customer often, and get feedback early. Break stuff down into small tasks that you are very confident about estimating time for. This is key. Focus on minimal functionality first - login, logout, visit home page, etc. before the real features. Use an Agile methodology. Talk to your client daily. Use software ...


7

You do have a project manager and technical lead on your project. For every project, every project role necessary is represented. In this case, there is only one person filling these roles: you. You have been managing single person projects since you were six. You have more PM skills than you are giving yourself credit for. There are certainly ...


5

"The many are smarter than the few" is a mantra I've taught to my agile teams for years. There is even a book, The Wisdom of the Crowd, founded on this very concept. I would promote full transparency for the very reason that by doing so you tap into the greater whole. One person can't see all the moving pieces and all the relationships. By sharing with all ...


4

As a reasonable person, I would always prefer an honest presentation of results over a fake perfect adherence to your initial estimate. But it is a sad reality that clients aren't always reasonable, and your fear isn't without merit. If you show your current status when the project actually commences, you might get caught in at least two traps in addition ...


4

You have no choice but to get the estimates and planning values--and risks thereof--from the vendors you are planning on using. Then you need to load those external commitments into your master schedule and read the resulting overall duration. Better yet, you would have a worst case duration value, best case, and most likely so you can fully understand ...


3

An easy solution would be to load the values in excel of your planned work, and then load the values of your actuals, and you can display progress using a cumulative graph. Here's an example: I used 155 as your planning value and loaded it assuming equal numbers each week, which produced a flat loaded schedule. Then I made up actual values but showed it ...


2

For our project management, we use Eylean. It is not nescecerally created for deveoping project timelines, as it offers more funtions, but with it you can create the exact timelines you described. It offers you a taskboard with all the tasks represented on the board. So the team can see which tasks are waiting to be started, which ones are in progress and ...


2

Sounds like the real problem is one of schedule and uncertainty; I actually envy you - if people are changing dates that often that means that they care about the schedule. I don't know why your dates are fluid - the answer to that question may provide deep insight. I'll provide some answers based on my experience. I use a couple of techniques to deal with ...


2

I would divide it into 4 parts - each one month long, with a milestone at the end of each month: Definitions - ending with a milestone of agreed upon feature spec Create initial sites - ending with a milestone of beta sites Testing beta sites - ending with a milestone of list of fixes for launch Finalizing sites - ending with a milestone of launch live ...


2

Group the requirements up into Epics (or Feature Groups or however you want to call them...) Developers estimate for the individual requirements, and then those are aggregated into the Epics - the Epics are then used to build the schedule.


2

You are the project manager on this project. You need to plan, you need to allocate tasks to yourself and to your co-developer, and you need to manage the contact with your client. David Espina is absolutely right about that. Every task takes time, and so you should plan accordingly. Client meetings, discussions with your colleague, and simply taking time ...


2

Let us assume that you have a completed Technical Spec, where everything is well defined. Note that the answers overlap and complement each other. How many front-end developers are needed? Assuming you are going to use the same language for both platforms, but it's completely different code then the answer depends on how fast you want it completed. If ...


2

You might use Logging time. As defined in ITIL, this is the Process to record and prioritize the Incident with appropriate diligence, in order to facilitate a swift and effective resolution. More info at https://wiki.en.it-processmaps.com/index.php/Incident_Management As a side note, I'd suggest to use the whole nomenclature already defined by ITIL. It'll ...


2

Primarily it depends upon how mature your suppliers are. If your suppliers are mature, then can trust them to see the whole picture and deal with the delays in a way that is best for them and all concerned. If they are not mature, then they may be tempted to simply use up any new time, or use it to mask their own issues that they have not yet informed you ...


1

There's a ton of different types of projects where the sponsor and stakeholders have little oversight or involvement so, if your project was like that, I don't think anyone would care that you did work before the project was supposed to start and you'll finish ahead of schedule. A lot of projects finish late so it's good to come in early when you have that ...


1

If he (client) wants to basically know where you are at on the project you can make one weekly product burndown chart. I will give you one template Good luck


1

Checking the first issue created (<PROJECT>-1) would give you a fairly acceptable ballpark date, unless by 'project' you mean something else that's not the actual Jira project. Either way, take into account that this information, out of context, might be just data, not an actual information.


1

Ultimately, you need to do what is going to give your project the best chance of success. While notifying other suppliers that the baseline has moved may help them run their business more smoothly, consider: It increases risk by complicating the situation. Your other suppliers now have a change to their deadline, that can lead to new risks that wouldn't ...


1

You can change the format of the dates in the timescale (area above Gantt chart) but you cannot define your own time periods, nor add custom text. I'd suggest using Middle Tier in Weeks with the label of Week 1, Week 2 or something similar. Right click on the timescale and choose Timescale from the shortcut menu.


1

I was disappointed with PWA's timeline functionality because it wouldn't match my project's timeline. Some callout tasks would be misplaced and overlap each other in PWA while everything looked good in the MS Project 2013 file. The text color in the bars would always be black, regardless of what it was in the Project file. As a workaround, I took a ...


1

The reliability in pregnancy is much higher than any type of work task. It is 266 days from conception, with only a very small variability except when you have something that is abnormal. Task duration is not like that, where "normal" can have a much larger range. Therefore, creating a tool like this for work would have an extremely low reliability and, ...


1

There are lots of software products that could fit your needs, as what you need is basically the ABC of a project management software. Maybe you should first have a look at this Wikipedia article: Comparison of project-management software


1

Check out the evidence based scheduling from Fogbugz: http://www.fogcreek.com/fogbugz/evidence-based-scheduling/


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