Review & Update Project Management Requirements & Approach

[mheadd]

In Section 3.03, the exiting language on project management requirements needs to be reviewed and possibly updated.

Similarly., Section 4.04 needs to be reviewed for possible updates.

[randyhart]

@waldoj @sztaylorakgov @mheadd I'm going to assign this to you all based on what you're experiencing with the DPA project. If there's lessons learned from the Search RFP, please feel free to edit. If not, please make note of it here.

[waldoj]

I don't think I see any changes that are necessary, based on our experience with DPA. We haven't experienced any project management problems that fell outside of the scope of these requirements, or that would appear to necessitate changes to the RFP.

[mheadd]

The only possible change I can think of is to possible change Links to relevant Github branches to simply refer to git branches. That might keep it generic enough to accommodate Github, VSTS or TFS (assuming we'll target git in any one of those).

[sztaylorakgov]

I'm guessing this is the same language we used for DPA? I did not notice these items last time from section 3.03:

Screenshot, links, or other documentation from the contractor’s project management system reflecting completed features, including number and percentage of completed sprint tasks (e.g. percentage of tasks completed) Ongoing access to the contractor’s project management tool to view development status

Are/were we envisioning separate project management tooling from VSTS? If the contractor does keep separate PM information, then we certainly want access to it. However, I'm not clear that we want to imply they should be doing that. Thoughts @mheadd?

[mheadd]

@sztaylorakgov Yup - this is the same language we used for DPA/Unified Search.

Agreed on your thoughts on the last two bullets. Maybe we add "If appropriate,..." to the beginning of those items? Ideally, they would be using whatever system the state deems appropriate - TFS, VSTS, etc.

[ghost]

On another project we just went through discussion about Microsoft tools and open source dev environments. It appears that TFS isn't really an option for an open source environment, while VSTS is. So assuming the plan is for open source here I think we might want to plan on VSTS or GitHub and not TFS.

[waldoj]

Neither VSTS nor TFS are good for open source, because neither of them have any concept of public repositories. Everything is inherently closed. The solution to this is to automatically push every Git commit out to a GitHub repo. That works equally well in VSTS and TFS.

But VSTS is much better for than TFS for providing vendors with access. TFS requires that vendors VPN into Alaska's environment to commit code, review open issues, etc. VSTS, as a cloud-hosted version of TFS, doesn't require that vendors have such access to Alaska's environment, which reduces administrative overhead for bringing on new vendors. This is the choice that we've made in our work with DPA, and it's going well.

In short, VSTS would be markedly better than TFS.

[randyhart]

@mheadd @sztaylorakgov we can either add "if appropriate", per Mark's suggestion, or leave it alone. I'm good with leaving it alone and closing the issue, but want a 👍 from both of you before doing so.

[mheadd]

If we opt to add the language, there's already a pull request in the queue for that. If we opt not to, we can just close the PR without merging.