FAQ-02

Project Overview and Objectives

Q: What is the primary objective of this project?
To create a user-friendly GUI for managing disk allocation, integrated with a backend EMS tool via API, to streamline disk management for projects.
Q: Why are we focusing on disk allocation management?
To improve resource efficiency, reduce manual errors, and provide real-time control over disk usage across projects.
Q: What problem does this project aim to solve?
It addresses the inefficiency and complexity of manually managing disk space, especially as project data grows.
Q: How does this align with company goals?
It enhances operational efficiency and supports our goal of automating IT resource management.
Q: What are the key deliverables?
A GUI interface, API integration with the EMS tool, and functions to extend or shrink disk allocations.
Q: Is this a new system or an upgrade?
It’s a new system built from scratch to meet current and future needs.
Q: What’s the expected outcome for end-users?
A simple, intuitive way to manage disk space without needing deep technical knowledge.
Q: Are there specific performance goals?
Yes, we aim for near-real-time updates and a response time under 2 seconds for disk operations.
Q: Who requested this project?
It came from the IT operations team to address growing storage demands.
Q: How will we measure success?
By user adoption rate, reduction in manual disk management time, and error-free operations.

Scope and Requirements

Q: What’s in scope for the GUI?
Disk allocation monitoring, extension, and shrinking capabilities, all accessible via a graphical interface.
Q: What’s out of scope?
Hardware-level disk management and non-EMS tool integrations are not included.
Q: Will the GUI support multiple projects?
Yes, it will allow users to manage disk allocations across multiple projects simultaneously.
Q: What EMS tool are we integrating with?
We’re using the company’s existing EMS tool, which provides disk management APIs.
Q: What API functions will we use?
Functions to query disk usage, extend disks, and shrink disks as needed.
Q: Are there specific user roles for the GUI?
Yes, admins will have full control, while project managers will have limited, project-specific access.
Q: Do we need real-time disk usage updates?
Yes, the GUI should reflect changes within seconds of an API call.
Q: Can users manually override disk allocations?
Yes, but only admins, with proper logging for accountability.
Q: Are there security requirements for the API?
Yes, we’ll use token-based authentication and encrypt all API calls.
Q: What happens if the EMS tool is down?
The GUI will display a fallback status and queue requests until the tool is back online.

Timeline and Milestones

Q: When is the project due?
We’re targeting a launch by October 15, 2025.
Q: What are the key milestones?
GUI prototype by June 1, API integration by August 1, and testing by September 15.
Q: How long will the design phase take?
About three weeks, starting April 15, 2025.
Q: When will we test the API integration?
In the third week of August, after the initial backend setup.
Q: Is the timeline flexible?
Slightly, but we need to align with the Q4 IT rollout schedule.
Q: How much time is allocated for user testing?
Two weeks in September to ensure usability.
Q: When will we review the automation scripts?
During the design phase, around April 25, 2025.
Q: What’s the kickoff date?
April 10, 2025, next week.
Q: How often will we have progress updates?
Weekly, every Monday morning.
Q: Can we adjust deadlines if issues arise?
Yes, with a formal change request process.

Team and Resources

Q: Who’s on the project team?
You, a GUI designer, two backend developers, a QA engineer, and the design team engineer who wrote the scripts.
Q: Do we have enough resources?
We’re good for now, but might need an extra developer for API work.
Q: Who’s managing the project?
I’ll be the project manager, overseeing timelines and deliverables.
Q: Will the design team engineer join us?
Yes, part-time, to explain the automation scripts and assist with integration.
Q: Do we need training on the EMS API?
Yes, we’ll schedule a session with the EMS vendor in April.
Q: Are there budget constraints?
We’re capped at $120,000, including tools and labor.
Q: Who’s responsible for the GUI design?
Our GUI designer, with input from you and the team.
Q: Can we use existing tools for development?
Yes, we’ll leverage our current IDEs and testing frameworks.
Q: How many hours should we allocate weekly?
About 25 hours per team member to start.
Q: Will we need external help?
Possibly for API troubleshooting if we hit roadblocks.

Automation Scripts from Design Team

Q: What do the automation scripts do?
They automate disk extension and shrinking based on predefined thresholds.
Q: Who wrote these scripts?
An engineer from the design team, Alex, who’s familiar with the EMS tool.
Q: Are the scripts already tested?
Partially—they’ve been tested in a sandbox but not in production.
Q: What language are the scripts written in?
Python, using the EMS API SDK.
Q: Can we modify the scripts?
Yes, Alex will provide documentation for us to adapt them.
Q: How do the scripts interact with the EMS tool?
They call the API to monitor usage and trigger disk changes.
Q: Are there limitations to the scripts?
They don’t handle multi-project scenarios yet—that’s on us to enhance.
Q: How often do the scripts run?
Currently, every 15 minutes, but we can adjust that.
Q: Can the GUI trigger these scripts?
That’s the plan—we’ll integrate them as backend functions.
Q: Will Alex demo the scripts for us?
Yes, during our next meeting on April 20, 2025.

Technical Details

Q: What tech stack will the GUI use?
We’re leaning toward React for the frontend, with a Node.js backend.
Q: How will the GUI connect to the EMS API?
Via RESTful API calls from the Node.js backend.
Q: What’s the max disk size we’ll support?
Up to 10TB per project, per EMS tool limits.
Q: Can we shrink disks below a minimum?
Yes, but we’ll set a safety threshold to avoid data loss.
Q: Will the API handle bulk operations?
Yes, it supports batch requests for multiple disks.
Q: How do we handle API rate limits?
We’ll implement throttling and queue excess requests.
Q: What’s the data format for API responses?
JSON, which we’ll parse for the GUI display.
Q: Do we need to log disk changes?
Yes, all actions will be logged for auditing.
Q: Can the GUI show historical disk usage?
Yes, if the EMS API provides that data—we’ll confirm.
Q: How do we test the shrink function?
In a staging environment with dummy data first.

Risks and Challenges

Q: What’s the biggest risk you see?
API downtime or instability could halt operations.
Q: How do we mitigate API issues?
By caching recent data and building retry logic.
Q: Could the scripts fail in production?
Possible if thresholds aren’t tuned—we’ll test thoroughly.
Q: What if the GUI isn’t user-friendly?
We’ll iterate based on user feedback during testing.
Q: Are there security risks with the API?
Yes, but encryption and access controls will minimize them.
Q: What if disk shrinking causes data loss?
We’ll enforce backups before any shrink operation.
Q: Could team bandwidth be an issue?
Potentially—we’ll monitor and adjust workloads.
Q: How do we handle scope creep?
Stick to the defined requirements unless formally approved.
Q: Are there dependencies on other teams?
Just the design team for script handoff.
Q: What’s the contingency plan?
Manual disk management as a fallback until issues are resolved.

Proposal and Next Steps

Q: What should our proposal include?
A detailed plan for GUI design, API integration, and script enhancements.
Q: When is the proposal due?
By May 1, 2025, after we review the scripts.
Q: Who will review the proposal?
Me, the IT director, and the design team lead.
Q: Should we propose new script features?
Yes, like multi-project support and custom thresholds.
Q: How detailed should the proposal be?
Include timelines, resources, and a mockup of the GUI.
Q: Can we suggest alternative tools?
Only if the EMS API falls short—justify it clearly “
Q: Will the proposal need a budget?
Yes, break down costs within the $120,000 cap.
Q: Should we address risks in the proposal?
Absolutely, with mitigation strategies.
Q: Who’s leading the proposal effort?
You’ll coordinate it, with input from the team.
Q: Can we present the proposal in person?
Yes, we’ll schedule a review meeting.

Stakeholders and Communication

Q: Who are the key stakeholders?
IT ops, project managers, and the design team.
Q: How often do we update stakeholders?
Monthly, with ad-hoc updates for major milestones.
Q: What’s the communication tool?
Slack for daily updates, email for formal reports.
Q: Who’s the point of contact for the EMS vendor?
I’ll handle vendor communications.
Q: How do we handle stakeholder feedback?
Review it weekly and prioritize based on impact.
Q: Are stakeholders testing the GUI?
Yes, a small group will test in September.
Q: How do we escalate issues?
Bring them to me, and I’ll decide next steps.
Q: Will stakeholders see the scripts?
Only if they request it—we’ll focus on the GUI.
Q: How do we manage expectations?
Clear scope and regular progress demos.
Q: Who approves the final product?
The IT director, with stakeholder input.

Post-Launch Considerations

Q: What happens after launch?
We’ll monitor usage and gather feedback for updates.
Q: Is there a support plan?
Yes, IT ops will handle Tier 1 support.
Q: Will we maintain the scripts?
Yes, as part of ongoing enhancements.
Q: How do we measure post-launch success?
Via user satisfaction surveys and performance metrics.
Q: Are there plans for version 2?
Possibly, based on feedback and new needs.
Q: Who owns the system after launch?
IT ops, with our team as consultants.
Q: Will we document everything?
Yes, full docs for the GUI, API, and scripts.
Q: How do we hand off to support?
With a training session and detailed guides.
Q: Is there a warranty period?
60 days for bug fixes post-launch.
Q: What’s the next step after this meeting?
Review the scripts with Alex, then start drafting the proposal.